Michiel van Meersbergen wrote:
Hello list,
I'm running into some trouble with the SEC_PKCS7DecodeItem function. The input for this function is a PKCS#7 EnvelopedData object, which contains just one recipient, a session key (encrypted with the recipients' public key) and the encrypted contents, encrypted with the above mentioned session key.
A slight oddity is that the encryption algorithm used does not get recognized by NSS (it gives me "SEC_ERROR_NO_MODULE, because when it tries to find the corresponding mechanism this yields 0xFFFF, for which there are of course no appropriate modules).
The mechanism (ANSI-X9.42 DES3_CBC) is encoded as "1.2.840.10046.1.2", so I had to add it by using SECOID_AddEntry like so:
std::string strDES3CBCOid("\x2a\x86\x48\xce\x3e\x01\x02", 7);
Hmmm S/MIME uses DES3_CBC as:
1.2.840.113549.2.7 I wonder what is different between ANSI-X9.42 and S/MIME?
SECItem oDES3CBCOid;
oDES3CBCOid.type = siBuffer;
oDES3CBCOid.data = strDES3CBCOid.data();
oDES3CBCOid.len = strDES3CBCOid.length();
SECOidData oDES3CBC;
oDES3CBC.oid = oDES3CBCOid;
oDES3CBC.desc = "ANSI-X9.42-DES-EDE3-CBC";
oDES3CBC.mechanism = CKM_DES3_CBC;
oDES3CBC.supportedExtension = INVALID_CERT_EXTENSION;
SECOID_AddEntry(&oDES3CBC);
Now NSS does recognize the encryption algorithm used, but i get some unexplained results. First of all, the plain data which would be present in the returned ContentInfo structure is not 'plain' data at all, it seems to be encrypted still. It is other data than I entered into the function, so that leads me to believe that maybe the session key was not decrypted properly, or maybe the above added mechanism is wrong. Any help here?
It's quite possible that ANSI x9.42 means something different than the
standard S/MIME function. If it is only the first 8 bytes of output that
are different, then it's most likely an issue with the IV (in CBC mode
the rest of the stream is self correcting). If ANSIx9.42 encodes the IV
differently than S/MIME, NSS will end up getting the wrong IV.
Also, if I do not provide a callback function for SEC_PKCS7DecodeItem, I get only the last 7 bytes of the 'decrypted' data in the data field of the returned SECItem structure, while the len filed indicates that there should have been 15637 bytes. If I do provide a callback however, I can see that it gets called twice: the first time with 15630 bytes of data, the second time with the last 7 bytes. Is this (maybe) a bug?
No the callback is for streaming the data. The fact it will split up the
decoded output is normal.
Another 'oddity' I should mention, is that the PKCS#11 DLL which provides access to the appropriate certificates and keys will ask for the proper authentication itself - in other words, when a private-key function like 'decrypt', 'sign' or 'unwrap' is called, it checks if authentication is needed, and asks for a password (via a message box). So I never need to provide any password-callbacks, do I?
Are you running inside something like a browser, or is this your own
application. If the latter, you should depend on the application's
password callback, if the latter you will need to provide your own. The
description of what actually happens sound like you are inside a browser.
I hope I've explained matters properly, please blame my English skills if I haven't ... I do. ;-)
Michiel van Meersbergen
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates
starting at 1ยข/min.
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
