ietf-smime
[Top] [All Lists]

Re: Way Forward

2000-08-01 10:56:54
I agree with Eric.  It would be better to maintain compatibility with the
existing S/MIME v2 deployments by using the PKCS #1.5 version of RSA key
management.

If the vulnerability is the one Eric mentions, then it is not really
significant.  It relies on receiving a very specific error message that
indicates that the PKCS #1.5 formatting was incorrect.  It can be countered by
including this error with other types of decryption errors (such as DES padding
errors) or by allowing the decryption to proceed (with the wrong key) and
signaling failures in the integrity (signature or authentication) portion of the
message.  Netscape's version of SSL does exactly this - the SSL handshake fails
later in the sequence when the MAC calculation fails.

In fact, in S/MIME it is not likely that the sender would any sort of response
(error or otherwise) at all, which makes this attack impossible.  In addition
the requirement for 2^20 messages in an email environment makes it impractical
as well.

Again, I would like to see PKCS #1.5 included as the mandatory algorithm to
allow compatibility with existing deployments.

Terry Hayes
thayes(_at_)netscape(_dot_)com

Eric Rescorla wrote:

Russ Housley <housley(_at_)spyrus(_dot_)com> writes:
Issue:  Since the RSA patent is about to expire, Blake Ramsdell suggested
that the RSA algorithm become the mandatory to implement algorithm for key
management and signature.  It was pointed out that the current RSA key
management (PKCS#1 v1.5) has a known vulnerability, so the OAEP technique
should be employed instead.
I'm not sure what the rationale is for this and it seems to me to
present even more opportunities for incompatibility.  The
vulnerability in PKCS#1 1.5 is an adaptive chosen ciphertext attack
that requires order 2^20 messages to be processed by the recipient
with quite specific success or failure indications.  In most
applications, this isn't practical at all. Moreover, the attack is
easily countered with a simple set of checks.

-Ekr

[Eric Rescorla                                   ekr(_at_)rtfm(_dot_)com]


<Prev in Thread] Current Thread [Next in Thread>