pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz (Peter Gutmann) writes:
Now let's look at the way it's applied here. A rough outline of what's
contained in KeyAgreeRecipientInfo is:
originatorDH -- Originators DH values p, g, y = g^x mod p
recipientDH -- Recipients fixed DH values p, g, y' = g^x' mod p
nonce -- Extra material to mix in to ensure different keys are
produced
This is incorrect. Here's the ASN.1 for reference:
I'd abstracted it down to what was actually being processed for
KeyAgreeRecipientInfo, for the ASN.1 I assumed most people on the list would
already have a copy of the S/MIME spec so I didn't copy it all out.
Peter, my complaint is that you DIDN'T abstract it down. Your
text implies that p,q,g, are carried in the message. They are not.
Neither is y'. The text that you snipped makes this clear. I supplied
the ASN.1 merely as background for my comments.
This obscures a great amount of detail in the ES-DH case. To really compare
the level of complexity, let's assume that you have an underlying
implementation which does (or can do) either DH or Elgamal as a primitive
operation (it's a dozen or so lines of code using any common bignum library).
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.
In contrast to implement key transport (agreement) using a DH key as ES-DH
key, you need to implement a completely new RecipientInfo type with
associated
processing, and large amounts of X9.42 with the associated increase in
complexity and virtually guaranteed interoperability problems between
implementations.
I agree that there is some additional implementation complexity in
managing the new ASN.1 types. I don't consider it that substantial.
Moreover, once we've taken this one-time hit, we are able to use a
broader class of algorithms than before. (A number of elliptic curve
algorithms come to mind.)
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.
-Ekr
--
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]