Am 06.07.16 um 05:15 schrieb Dr. Stephen Henson:
...
Is the CMS object broken, or is this a problem in OpenSSL?
Well the OpenSSL version does interop OK with the Bouncy Castle version of
ECDH and CMS. I've checked through your test message and the problem is that
the AES unwrapping algorithm checks fail meaning it can't proceed any further.
That could be down to a CMS problem, an ECDH issue or a problem with the wrap
algorithm either in the version you are testing or OpenSSL.
Is it possible to get any debugging information from the other version you are
using: for example the content encryption key it is expecting or the ECDH
shared secret?
I don't know whether that is possible, I will check.
Have you tried generating an message with OpenSSL and decrypting it with the
other version?
Yes, the other version cannot decrypt the CMS object generated by
OpenSSL. I did some tests with Bouncy Castle, and it also cannot decrypt
the CMS object.
What might be interesting is that on the other hand Windows CryptoAPI is
able to decrypt the CMS object (tested on Windows 10).
While doing research on this, we found one thing that looks suspicious
in the CMS objects generated by OpenSSL 1.0.2. When dumping the CMS
object with dumpasn1, the key wrap algorithm is encoded as follows:
SEQUENCE {
OBJECT IDENTIFIER '1 3 132 1 11 3'
SEQUENCE {
OBJECT IDENTIFIER aes256-wrap (2 16 840 1 101 3 4 1 45)
NULL
}
}
Note the NULL parameter in the aes256-wrap algorithm identifier. Compare
that to RFC 3565, "2.3.2. AES CEK Wrap Process":
https://tools.ietf.org/html/rfc3565#section-2.3.2
"In all cases the parameters field MUST be absent."
Does this refer to the parameters field of the AlgorithmIdentifier of
the AES key wrap algorithm? Then it would be incorrect to include the
NULL here.
--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
