Subject: Re: Some comments on the use of DH in S/MIME

From: [email-masked] (Peter Gutmann)
Date: Thu, 24 Dec 1998 15:25:31 (NZDT)

>No more so than in the ElGamal case. The ElGamal bignum primitves are indeed
>simple, as are the DH ones. The implementation trickiness is in the symmetric
>wrapping stages. To correctly use ElGamal, you should use OAEP, which is not
>widely implemented.
 
Why would you want to do this (apart from adding unnecessary complexity)?
What's wrong with PKCS #1 wrapping?  The Elgamal X.509 profile draft has been
around for about a year and was also discussed in sci.crypt without anyone
claiming you needed OAEP (in fact strictly speaking you don't even need the
PKCS #1 block type 02 random padding since Elgamal is randomised anyway, but I
used it for consistency with the RSA usage).
 
>Similarly, X9.42 requires the expansion and key wrapping transforms. I
>consider these of approximately similar complexity, as I indicated in my
>previous message.
 
In terms of complexity the two aren't even in the same league!  Elgamal
requires one or two extra lines of code in an existing implementation while
X9.42 requires an entirely new RecipientInfo type, key wrapping, processing,
and whatnot, with accompanying interoperability problems.
 
>>KeyTransRecipientInfo is vastly less complex than adding a whole new
>>RecipientInfo type, and when they're providing exactly the same service I
>>really don't see why ES-DH should be the way to go (thus the "pushing a pea
>>up a mountain with your nose" quote in the previous message).
 
>Asked and answered. It's better, for technical reasons which I laid out in my
>previous message.
 
The only reasons were that in some special cases (that is, by re-using existing
cryptovariables, with its accompanying security problems) it was possible for
users to get their mail a few milliseconds faster than if Elgamal was used.
ES-DH, in return for a vast amount of unnecessary implementation complexity,
offers in return a minor speed tradeoff which noone will ever notice in
practice.  I just don't see the point of going to all this effort for no
obvious (to the user) return.
 
Peter.

---

From: EKR <[email-masked]>
Date: 23 Dec 1998 18:41:56 -0800

[email-masked] (Peter Gutmann) writes:

> What's wrong with PKCS #1 wrapping? 
The same sorts of issues that have been raised with respect to 
PKCS-1 in RSA are worth worrying about with ElGamal. In particular
see the Bleichenbacher attack. I don't know that these attacks are
feasible for ElGamal, but I'd rather not take chances.

> and whatnot, with accompanying interoperability problems.
Peter, I understand that you feel strongly about this, but please read
more carefully. What I wrote was:

  No more so than in the ElGamal case. The ElGamal bignum primitves
  are indeed simple, as are the DH ones. The implementation trickiness
  is in the symmetric wrapping stages. To correctly use ElGamal, you
  should use OAEP, which is not widely implemented. Similarly, X9.42
  requires the expansion and key wrapping transforms. I consider these
  of approximately similar complexity, as I indicated in my 
  previous message.

As I said previously, I agree that there is additional implementation
complexity in parsing te new ASN.1 structs, but the CRYPTO implementation
cost is fairly similar. In particular, OAEP and the X9.42 expansion/
wrapping transforms are of comparable cost. I stand by this statement.

> cryptovariables, with its accompanying security problems)
1. Those weren't the only reasons. As I indicated, the SS case
gives you data origin authentication.
2. I don't believe you are correct about the security problems.
What precisely do you believe the problem is with reusing 
the sender's key with ES-DH provided that you use a new pubInfo
for each message? I agree that there is a security issue
wrt to a shared group for SS mode, and that's why it's optional.

> it was possible for
I think you're overstating the amount of implementation complexity.
I estimate it as being no more than a day or two's work.

> practice.
You're missing the big picture: CMS is not just for email. For
interactive applications, this cost can become significant.
(Especially on the server side.) 

-Ekr
--
[Eric Rescorla                                   [email-masked]]