Crypto11 fails to perform decrypt operation #5

Activity

1. optnfast commented on Jul 31, 2018

   

   optnfast

   on Jul 31, 2018

   Contributor

   More actions

   This is (currently) a limitation of crypto11. If the SessionKeyLen option is nonzero then it refuses to decrypt. It is documented but I appreciate that it's easy to miss if you are using it as a drop-in replacement for the native implementation.

   The reason lies in the definition of the option:

       // SessionKeyLen is the length of the session key that is being
       // decrypted. If not zero, then a padding error during decryption will
       // cause a random plaintext of this length to be returned rather than
       // an error. These alternatives happen in constant time.
   

   The reason for this behavior is Daniel Bleichenbacher's attack on the PKCS#1v1.5 padding scheme.

   crypto11 could (hypothetically) replace error responses with random plaintexts, but it cannot guarantee the constant-time behavior - that is something that only the underlying PKCS#11 implementation can control.

   Rather than violate the promise in the API definition, I chose to have the code fail instead. I appreciate that this is not convenient, but I think it is the safer option.

   If it's a major problem then I think we could have a runtime option which accept nonzero SessionKeyLen values and set random plaintext without the promise of constant-time behavior. It would be off by default and accompanied by a warning about the security risks of enabling it.

   However, my recommendation is that you avoid ciphersuites that depend on PKCS#1v1.5 decryption, if that is possible.

   References:

   • https://en.wikipedia.org/wiki/Adaptive_chosen-ciphertext_attack
   • https://tools.ietf.org/html/rfc5246#section-7.4.7.1
   • http://archiv.infsec.ethz.ch/education/fs08/secsem/bleichenbacher98.pdf
2. vareddy-zz commented on Jul 31, 2018

   

   vareddy-zz

   on Jul 31, 2018

   Author

   More actions

   Hi @nfewx,
   Thanks a lot for the detailed explanation. The course of action you suggested looks good to me. I will close this issue.
   Thanks!
   Varun
3. vareddy-zz

   closed this as completedon Jul 31, 2018
4. optnfast

   added a commit that references this issue on Aug 1, 2018

   Document the SessionKeyLen limitation more explicitly

   ...

   391de63
5. dmjones

   added

   question

   invalid

   and removed

   question

   on Mar 14, 2019