EnvelopedCMS with AES and rsaEncryption (PKCS#1 v1.5 padding instead of v2 (OAEP) padding) possible?

Question

I\'ve been using .NET for cryptographic purposes a bit. Up to now, I used 3DES (Oid 1.2.840.113549.3.7) in combination with rsaEncryption (Oid 1.2.840.113549.1.1.1, RSAES-PK

Answer 1

The .NET Framework EnvelopedCms is built on top of Windows CAPI CryptMsg* functions. CryptMsgOpenToEncode supports two ways of encoding recipients, one of which is conditionally compiled (though I haven't been able to identify when it is not available; I suspect it's a Win9x vs NT4/WinXP compat problem).

On a whim I looked to see what could flip it to use the other codepath, and if that would change your result here. It turns out, yes, making it internally "useCms" results in the recipient encryption algorithm being 1.2.840.113549.1.1.1.

Option 1) Use SubjectKeyIdentifier identification

If you're interoperating with another system, as is the case here, make sure that the certificate has an explicit SubjectKeyIdentifier extension before using this identification form. .NET/Windows will make up an implicit value if there isn't an explicit one, and not all CMS implementations will match the recipient certificate in that case (e.g. OpenSSL).

You accomplish this by changing your CmsRecipient to

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

Option 2) Add an UnprotectedAttribute

EnvelopedCms allows for other metadata to be added onto the message unencrypted. Specifying any of these values makes the encryptor/encoder use the alternate codepath.

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 those worked in local testing.