slb20
slb20

Reputation: 139

CryptoAPI CNG and CMS functionality

I've got a question regarding Microsoft CNG which substitutes Crypto API. Since I have a project/assignment where I need to use CMS/PKCS#7 with RSA-OAEP encryption and RSASSA-PSS signatures.

But I am confused about whether CNG (not the legacy support for CryptoAPI) includes CMS functionality or not. On the feature list it clearly states that protocols such as CMS are supported ( https://msdn.microsoft.com/de-de/library/windows/desktop/bb204775(v=vs.85).aspx ) but I can only find methods belonging to the CryptoAPI which deal with PKCS#7/CMS messaging:

So far I have only found the Crypto API "Low-level Message Functions" and "Simplified Message Functions" ( https://msdn.microsoft.com/en-us/library/windows/desktop/aa380252(v=vs.85).aspx )

Could you please point out if CMS is only available through aforementioned CryptoAPI or is there any new CNG method I have missed?

Thanks in advance

Upvotes: 2

Views: 1159

Answers (2)

bartonjs
bartonjs

Reputation: 33266

The layering is the opposite of what you've asked. CNG provides the cryptographic primitives (it understands RSA). The Win32 CryptMsg* APIs understand CMS.

If you are using Win32 directly you can use either CNG or CAPI keys with CryptMsg*. For example, to decrypt a message you would call CryptMsgControl(msg, 0, CMSG_CONTROL_DECRYPT, &para). The parameter for a CMSG_CONTROL_DECRYPT is a CMSG_CONTROL_DECRYPT_PARA, which has a union field for either an HCRYPTPROV (CAPI) or an NCRYPT_KEY_HANDLE (CNG).

.NET's built-in EnvelopedCms and SignedCms classes should be able to decrypt and verify RSA-OAEP and RSA-PSS, respectively. But since they both use the certificate key algorithm OID for determining how to create a message (a scheme which worked great, until it didn't) they can only create PKCS#1 v1.5 compatible ciphertext and signatures.

Upvotes: 2

Maarten Bodewes
Maarten Bodewes

Reputation: 94058

No, the Cryptographic Next Generation API is a relatively low level API which doesn't contain higher up protocols like CMS (PKCS#7 is the standard that specifies CMS).

CMS is mentioned in a long list of protocols that it is designed to support:

One of the key value propositions of CNG is cryptographic agility, sometimes called cryptographic agnosticism. Converting implementation of protocols like Secure Sockets Layer protocol (SSL) or transport layer security (TLS), CMS (S/MIME), IPsec, Kerberos, and so on, to CNG, however, was required to make this ability valuable. At the CNG level, it was necessary to provide substitution and discoverability for all the algorithm types (symmetric, asymmetric, hash functions), random number generation, and other utility functions. The protocol-level changes are more significant because in many cases the protocol APIs needed to add algorithm selection and other flexibility options that did not previously exist.

So here it talks about the agility of the CNG library so that the implementation of higher level protocols can use the CNG API. So it talks for instance about the conversion of the implementation of CMS on top of the old CryptoAPI to an implementation that uses the .NET CNG API.

I do think that this is not significantly clear the way it is written. The fact that the API still contains a few constants required to implement CMS doesn't help.


The result of the conversion/porting, of course, can be found here which - rather stupidly - throws all the functionality found in the PKCS standards together in one single namespace. You probably are mainly interested in the EnvelopedCMS (for encryption) and SignedCMS classes and everything surrounding it.

Upvotes: 0

Related Questions