Opened 13 years ago
Closed 9 years ago
#6308 closed defect (wontfix)
MD5 encoding is not done on strings using UTF8
Reported by: | guest | Owned by: | Tom Trenka |
---|---|---|---|
Priority: | high | Milestone: | future |
Component: | Dojox | Version: | 1.0 |
Keywords: | MD5 UTF8 UTF16 | Cc: | |
Blocked By: | Blocking: |
Description (last modified by )
MD5 encoding is not done using an utf8 version of the string. This results in a different md5 than is expected for utf8 encoded pages.
The original library the dojo MD5 functionality was based on has an updated version (?alpha?) which always does the utf16 => utf8 encoding.
Change History (7)
comment:1 Changed 13 years ago by
Component: | General → Dojox |
---|---|
Owner: | changed from anonymous to Tom Trenka |
comment:2 follow-up: 3 Changed 13 years ago by
Milestone: | → 1.3 |
---|---|
Status: | new → assigned |
Yes, it's mine. And the version of MD5 in the repo does not support unicode. But I'll see if an update is warranted.
The main issue is that if one gets updated to use double-byte character sets, all must be updated and I'm not entirely sure I want to support that yet.
comment:3 follow-up: 4 Changed 13 years ago by
Replying to ttrenka:
The main issue is that if one gets updated to use double-byte character sets, all must be updated and I'm not entirely sure I want to support that yet.
The issue we encountered was with high order ASCII (above 128). Our backend is all utf8 (MySQL / PHP) and the forms are all utf8 but when the JS layer encodes the high order ascii the UTF8 != UCS2 encoding.
For example "§": ASCII: 0xA7 (167) UCS2: 00A7 UTF8: C2A7
Each of these results in a different MD5 being generated and makes digest comparison quite difficult.
comment:4 Changed 13 years ago by
Description: | modified (diff) |
---|
Understood; I will see what I can do.
BTW, you do realize that MD5 has been brute-forced, right?
Replying to guest:
Replying to ttrenka:
The main issue is that if one gets updated to use double-byte character sets, all must be updated and I'm not entirely sure I want to support that yet.
The issue we encountered was with high order ASCII (above 128). Our backend is all utf8 (MySQL / PHP) and the forms are all utf8 but when the JS layer encodes the high order ascii the UTF8 != UCS2 encoding.
For example "§": ASCII: 0xA7 (167) UCS2: 00A7 UTF8: C2A7
Each of these results in a different MD5 being generated and makes digest comparison quite difficult.
comment:5 Changed 13 years ago by
Milestone: | 1.3 → 1.4 |
---|
comment:6 Changed 13 years ago by
Milestone: | 1.4 → future |
---|
comment:7 Changed 9 years ago by
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
I'm going to close this ticket; it's pretty old and I have no plans on supporting UTF-8 in encoding at this time (at least for the 1.0+ line of DTK).
This is presumably for DojoX crypto... Tom, is that yours?