On Mon, 2016-08-29 at 18:40 +0100, David Woodhouse wrote: > > So... let's have a password 'nałve', in a ISO8859-2 environment where > that is represented by the bytes 6e 61 b3 76 65. > > First I should try the correct version according to the spec: > 006e 0061 0142 0076 0065 > > Then we try the "OpenSSL assumed it was ISO8859-1" version: > 006e 0061 00b3 0076 0065 > > And finally we try the "OpenSSL assumed it was UTF-8" version: > 006e 0061 ... actually you *can't* convert that byte sequence "from" > UTF-8 since it isn't valid UTF-8. So what will new OpenSSL do here, > again?
In this specific example (the byte stream is not valid UTF-8 it looks like OPENSSL_utf8touni() will assume it's actually ISO8859-1 and thus the final case will be identical to the previous one. So let's try a better example. The password is "ĂŻ" (U+0102 U+017b), and the locale (not that it *should* matter) is ISO8859-2. The correct rendition is 01 02 01 7b. The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be to *convert* to ISO8859-2 (giving c3 af). Then to interpret those bytes as ISO8859-1 (in which they would mean "ï") and convert *that* to UTF16LE to give 00 c3 00 af The "new buggy OpenSSL" rendition, again in the ISO8859-2 locale, would again be to convert to ISO8859-2 (c3 af). Then to interpret those bytes as UTF-8 (in which they would mean "ï") and convert *that* to UTF16LE to give 00 ef. Right? -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev