From 6fc530e6a0c88ab39d9840fcb47650ad4e471058 Mon Sep 17 00:00:00 2001 From: "Dr. Stephen Henson" Date: Tue, 15 Apr 2014 18:17:12 +0100 Subject: [PATCH] Clarify CMS_decrypt behaviour. (cherry picked from commit 5f8e9a477a18551052f2019c1f374061acbaa5e6) --- doc/crypto/CMS_decrypt.pod | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/doc/crypto/CMS_decrypt.pod b/doc/crypto/CMS_decrypt.pod index d857e4f93f..3fa9212af3 100644 --- a/doc/crypto/CMS_decrypt.pod +++ b/doc/crypto/CMS_decrypt.pod @@ -27,7 +27,21 @@ function or errors about unknown algorithms will occur. Although the recipients certificate is not needed to decrypt the data it is needed to locate the appropriate (of possible several) recipients in the CMS -structure. If B is set to NULL all possible recipients are tried. +structure. + +If B 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 then 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 B is set +then the above behaviour is modified and an error B returned if no +recipient encrypted key can be decrypted B generating a random +content encryption key. Applications should use this flag with +B 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 looking them up in a database) and setting them in the CMS structure -- 2.25.1