On Thu Mar 20 09:09:31 2014, mbev...@google.com wrote: > The "openssl pkcs8" CLI tool fails to properly decrypt a file containing an > EncryptedPrivateKeyInfo structure encrypted with an empty password (see > error below). This happens when a PKCS #12 algorithm is used (such as > PBE-SHA1-3DES); I have not investigated PKCS #5 algorithms. I hit this bug > when attempting to decrypt Chrome's Channel ID/Origin Bound Certs private > keys which are encrypted by (non-broken) NSS. >
Unfortunately I've come across implementations that use both forms so it isn't just a case of fixing a bug. In more detail. The original PKCS#12 PBE didn't give details of how the password was formatted. Previously for PKCS#5 there was an unwritten rule that the ASCII form without a terminating null was used. Existing public browser PKCS#12 implementations used the unicode representation of the password and included the double zero byte terminator, text was added to later versions of the standard clarifying this. The use of the double null terminator has resulted in some ambuguity. Should a zero length password be treated as literally zero length or empty? If it is zero length the double zero is all that is passed to the algorithm (i.e. two bytes). If it is empty then nothing is used, zero bytes. I've come across both forms so whatever you do it will break something. Some of the OpenSSL code partially works around this issue. Normally PKCS#12 PBE algorithms are only present in PKCS#12 files. The function PKCS12_parse tests both an empty and zero length password against the MAC and uses whichever works. See the note in p12_kiss.c. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
