[openssl-project] To use or not use the iconv API, and to use or not use other libraries

Richard Levitte levitte at openssl.org
Mon Jun 11 15:40:17 UTC 2018

In message <8EE45344-9BFC-44F9-9DB2-C384F7645CD6 at akamai.com> on Mon, 11 Jun 2018 15:25:23 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> >    *must* do when getting '-pass8bit' is to do a naïve UTF-8 encode of
rsalz>     the input pass phrase string.  PKCS12_generate_mac() will then decode
rsalz> I disagree.
rsalz> There are two reasons why users enter "illegal" passwords now,
rsalz> and by now requiring them to make it explicit we can (a) check
rsalz> only for ASCII on current inputs; (b) make them thing about
rsalz> what they're doing and require them to specify; (c) set the
rsalz> expectation that something will change in the future.

[btw, PKCS12_gen_mac(), not PKCS12_generate_mac()]

So wait, if the user enters this:

    openssl pkcs12 -export -in foo.pem -out foo.p12 \
        -pass8bit -password pass:`echo 72c3a46b61 | xxd -r -p`

...  then it seems "natural" that the user would expect the resulting
BMPString to become this set of bytes, right?

    0x00, 0x72, 0x00, 0xc3, 0x00, 0xa4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00

However, what's going to happen is that PKCS12_gen_mac() will generate
this for a BMPString:

    0x00, 0x72, 0x00, 0xe4, 0x00, 0x6b, 0x00, 0x61, 0x00, 0x00

Why?  Because the input pass phrase can be interpreted as a UTF-8
encoded string, and PKCS12_gen_mac() will decode it thusly.

>From a user interface point of view, I would fine such behavior very
surprising, and not at all what I'd expect for a flag named '-pass8bit'


Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

More information about the openssl-project mailing list