pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz (Peter Gutmann) writes:
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 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.
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.
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.
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)
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
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,
I think you're overstating the amount of implementation complexity.
I estimate it as being no more than a day or two's work.
offers in return a minor speed tradeoff which noone will ever notice in
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 ekr(_at_)rtfm(_dot_)com]