EnvelopedCMS with AES and rsaEncryption (PKCS # 1 v1.5 add-on instead of v2 add-on (OAEP))?

Question

I used .NET for cryptographic purposes. So far I have used 3DES (Oid 1.2.840.113549.3.7) in combination with rsaEncryption (Oid 1.2.840.113549.1.1.1, RSAES-PKCS1-v1_5). While the first one should now be replaced with AES (Oid 2.16.840.1.101.3.4.1.42), I still have to use rsaEncryption / RSAES-PKCS1-v1_5 , not RSAES-OAEP .

If I just pass an additional argument to the EnvelopedCMS constructor that I call, I can switch from 3DES to AES:

ContentInfo plainContent = new ContentInfo(new Oid("1.2.840.113549.1.7.1"), data); EnvelopedCms encryptedMessage = new EnvelopedCms(plainContent); // using 3DES // EnvelopedCms encryptedMessage = new EnvelopedCms(plainContent, new AlgorithmIdentifier(new Oid("2.16.840.1.101.3.4.1.42"))); // for AES (id-aes256-CBC) CmsRecipient recipient = new CmsRecipient(cert); encryptedMessage.Encrypt(recipient); byte[] encryptedBytes = encryptedMessage.Encode(); 

It is still. Unfortunately, some recipients cannot decrypt my messages, although they can decrypt AES. Looking at the structure of ASN.1, I tell you that not only 3DES changed to AES, but rsaEncryption (1.2.840.113549.1.1.1) was replaced by RSAES-OAEP (1.2.840.113549.1.1.7). Can I somehow make everyone still use RSAES-PKCS1-v1_5 with EnvelopedCMS? Or do you see another problem when switching 3DES-> AES?

Edit: In case I cannot change the add-on easily available for v1.5, what other options do I have? Manually call CryptoServiceProviders and create the PKCS # 7 envelope yourself? Are there any more elegant ways?

Answer 1

The .NET Framework EnvelopedCms is built on top of the CAPI features of CryptMsg * Windows. CryptMsgOpenToEncode supports two methods of encoding recipients, one of which is conditionally compiled (although I could not determine when it is unavailable, I suspect that this is a Win9x vs NT4 / WinXP problem).

On a whim, I looked that you can flip to use a different encoding, and if that changes your result here. Turns out yes, this makes internally "useCms" the result in recipient encryption algorithm 1.2.840.113549.1.1.1.

Option 1) Use SubjectKeyIdentifier

If you interact with another system, as is the case, make sure that the certificate has an explicit SubjectKeyIdentifier extension before using this form of identification .. NET / Windows will be implicit if not explicit, and not all CMS implementations will match the recipient certificate in this case (e.g. OpenSSL).

You accomplished this by changing your CmsRecipient to

 CmsRecipient recipient = new CmsRecipient(SubjectIdentifierType.SubjectKeyIdentifier, cert); 

Option 2) Add UnprotectedAttribute

EnvelopedCms allows you to add other metadata to an unencrypted message. Specifying any of these values ​​forces the encryptor / encoder to use an alternative encoding.

Before calling Encrypt add

 // Pkcs9DocumentName requires a non-empty string. // You can use any AsnEncodedData value, though. encryptedMessage.UnprotectedAttributes.Add(new Pkcs9DocumentName("a")); 

Each of them worked in local testing.