Wan-Teh Chang wrote:
I don't know either. Does anyone know?Does the lack of a SECOidTag for CKM_DES3_ECB prevent you from using some NSS functionality? I did some web searches for the OID. The OID for DES-EDE is "1.3.14.3.2.17": http://www.alvestrand.no/objectid/1.3.14.3.2.17.html But I'm not sure if that's the ECB mode. NSS's SECOidTag for this OID is SEC_OID_DES_EDE. In our OID table, this OID doesn't correspond to any PKCS #11 mechanism: http://mxr.mozilla.org/security/source/security/nss/lib/util/secoid.c#611 611 OD( desede, SEC_OID_DES_EDE, 612 "DES-EDE", CKM_INVALID_MECHANISM, INVALID_CERT_EXTENSION ),
For now I have marked the CKM_DES3_ECB mechanism as not supported for now, what I was keen to do was make sure it wasn't something stupid that I was doing.
I have finally managed to commit the abstraction I was working on here for wider review:
https://svn.apache.org/repos/asf/apr/apr-util/trunk/crypto/apr_crypto_nss.cPart of the effort was to create an interoperability test, to demonstrate that a string encrypted with NSS could be decrypted with OpenSSL and vice versa.
The following four OIDs could be successful encrypted then decrypted with the same library, but didn't interoperate. In other words, NSS could decrypt the string if encrypted with NSS, but not if it was encrypted with OpenSSL. Obviously there is no way to tell whether this is OpenSSL's fault or NSS's fault.
Are the following four OIDs supported by NSS? SEC_OID_AES_128_CBC SEC_OID_AES_128_ECB SEC_OID_AES_192_CBC SEC_OID_AES_192_ECB Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
