-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PKCS12 KDF + MD2 incorrect result #4267
Comments
Thanks for the report! It seems a bit puzzling that the discrepancy occurs only with MD2 and no other hash function. By any chance, did you investigate or have any idea why that might be? |
Unfortunately I haven't looked at the cause, however I can say that MD2 in mbed TLS works correctly as a digest, as a HMAC, and as a HKDF and a PBKDF2. |
PKCS#12 explicitly specifies that v = 512 bits = 64 bytes for MD2, corresponding to the width of the compression function that it uses internally. However, most implementations of PKCS#12 use v = 128 bits = 16 bytes, corresponding to the amount of input that gets processed by one iteration of the compression function. MD2 is the only common hash function for which these two quantities are different. Mbed TLS classically used the value from the standard, but this made it incompatible with the rest of the world. Fix Mbed-TLS#4267. Signed-off-by: Gilles Peskine <[email protected]>
PKCS#12 explicitly specifies that v = 512 bits = 64 bytes for MD2, but this is an incorrect application of the general rule of using the size of "the message input to the compression function", i.e. the block size, which is 128 bits = 16 bytes. Mbed TLS classically used the explicit value from the specification, but this made it incompatible with the rest of the world, so change to follow the generic rule from the specification, which is also the de facto standard. Fix Mbed-TLS#4267. Signed-off-by: Gilles Peskine <[email protected]>
This intrigued me, so I looked at what could be special about MD2. PKCS#12 states:
RFC 7292 has similar language. The specification is inconsistent: the size of the message input to the compression function is 128 bits, not 512 bits. Mbed TLS uses the explicit value stated in the specification, but most other implementations follow the generic rule of using the block size. I verified on https://github.com/gilles-peskine-arm/mbedtls/tree/pkcs12-md2 that changing to use the block size causes Mbed TLS to produce the same output as libtomcrypt and crypto++. (The patch in that branch is probably not what we want: we should probably use @guidovranken Did you find any other implementation that produces the same output as Mbed TLS? |
In my fuzzer the only other libraries that support PKCS12 KDF are wolfCrypt and OpenSSL. wolfCrypt doesn't support PKCS12 KDF + MD2. OpenSSL 1.1.1k produces the same result as Crypto++ and libtomcrypt. |
On a related note, it might interest you that there are two interpretations of the DES-X cipher: openssl/openssl#9703 (comment) |
Parameters:
mbed TLS produces:
Both libtomcrypt and Crypto++ produce:
So I am assuming the mbed TLS output is incorrect.
A discrepancy only occurs with PKCS12 KDF + MD2, not any other hash functions.
This is how I invoke PKCS12 KDF in mbed TLS: https://github.com/guidovranken/cryptofuzz/blob/f1b8e13c1dfd695da0f15268ffe99d4b0ae7ef64/modules/mbedtls/module.cpp#L734-L743
The text was updated successfully, but these errors were encountered: