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.