CMS_DECRYPT(3) | Library Functions Manual | CMS_DECRYPT(3)

# NAME

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

# SYNOPSIS

library “libcrypto”
`#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`().

June 8, 2025 | Debian