NAME¶

CMS_decrypt, CMS_decrypt_set1_pkey, CMS_decrypt_set1_key — decrypt content from a CMS EnvelopedData structure

SYNOPSIS¶

#include <openssl/cms.h>

int
CMS_decrypt(CMS_ContentInfo *cms, EVP_PKEY *private_key, X509 *certificate, BIO *dcont, BIO *out, unsigned int flags);

int
CMS_decrypt_set1_pkey(CMS_ContentInfo *cms, EVP_PKEY *private_key, X509 *certificate);

int
CMS_decrypt_set1_key(CMS_ContentInfo *cms, unsigned char *symmetric_key, size_t keylen, const unsigned char *id, size_t idlen);

DESCRIPTION¶

CMS_decrypt() extracts and decrypts the content from the CMS EnvelopedData structure cms using the private_key and the certificate of the recipient. It writes the decrypted content to out.

In the rare case where the compressed content is detached, pass it in via dcont. For normal use, set dcont to NULL.

Although the recipient's certificate is not needed to decrypt the data, it is needed to locate the appropriate (of possibly several) recipients in the CMS structure.

If the certificate is set to NULL, all possible recipients are tried. This case however is problematic. To thwart the MMA attack (Bleichenbacher's attack on PKCS #1 v1.5 RSA padding), all recipients are tried whether they succeed or not. If no recipient succeeds, a random symmetric key is used to decrypt the content: this will typically output garbage and may (but is not guaranteed to) ultimately return a padding error only. If CMS_decrypt() just returned an error when all recipient encrypted keys failed to decrypt, an attacker could use this in a timing attack. If the special flag CMS_DEBUG_DECRYPT is set, the above behaviour is modified and an error is returned if no recipient encrypted key can be decrypted without generating a random content encryption key. Applications should use this flag with extreme caution especially in automated gateways as it can leave them open to attack.

It is possible to determine the correct recipient key by other means (for example by looking them up in a database) and setting them in the cms structure in advance using the CMS utility functions such as CMS_decrypt_set1_pkey(). In this case both certificate and private_key should be set to NULL when calling CMS_decrypt() later on.

To process KEKRecipientInfo types, CMS_decrypt_set1_key() or CMS_RecipientInfo_set0_key(3) and CMS_RecipientInfo_decrypt(3) should be called before CMS_decrypt() and certificate and private_key set to NULL when calling CMS_decrypt() later on.

If the CMS_TEXT bit is set in flags, MIME headers for type text/plain are deleted from the content. If the content is not of type text/plain, an error occurs.

RETURN VALUES¶

CMS_decrypt(), CMS_decrypt_set1_pkey(), and CMS_decrypt_set1_key() return 1 for success or 0 for failure. The error can be obtained from ERR_get_error(3).

SEE ALSO¶

CMS_ContentInfo_new(3), CMS_encrypt(3), CMS_get0_RecipientInfos(3)

STANDARDS¶

RFC 5652: Cryptographic Message Syntax (CMS)

• section 6.1: EnvelopedData Type
• section 6.2.3: KEKRecipientInfo Type

HISTORY¶

CMS_decrypt(), CMS_decrypt_set1_pkey(), and CMS_decrypt_set1_key() first appeared in OpenSSL 0.9.8h and have been available since OpenBSD 6.7.

BUGS¶

The lack of single pass processing and the need to hold all data in memory as mentioned in CMS_verify(3) also applies to CMS_decrypt().