ietf-smime
[Top] [All Lists]

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

1998-12-24 15:22:53
pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz (Peter Gutmann) writes:

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.
 
I don't have Bleichenbachers paper in front of me right now but as I recall it
applied only to Elgamal *signatures* (the title is a sure giveaway, it was
something like "How to generate Elgamal signatures without knowing the key").
I'm referring to the Bleichenbacher attack on RSA key transport,
aka the "Million Message Attack." I don't believe it's known that this cannot
be extended to ElGamal. I prefer not to take chances.

I agree with you 100%.  If you use OAEP then they're probably of roughly
similar complexity.
 
Since there's no need to use OAEP, it's also obvious that DH as Elgamal is
vastly simpler than DH as ES-DH.  QED.
I'm not convinced that there's no need to use OAEP. As Mihir Bellare
is fond of pointing out, when you're designing new protocols, it's good
to protect against attacks you don't know about as well as attacks
you do. Hence a provably secure padding algorithm seems like a good
choice.

I was referring to Static-Static, cached (ie reused) cryptovariables, etc etc:
 
  As noted above, it can be run in a Static-Static mode which requires half as
  many modular exponentiations as either ElGamal or ES, and also provides Data
  Origin Authentication. If you cache ZZ, the number of exponentiations per
  message drops to zero (a la SKIP).
Fair enough. However, there are caching optimizations available when you
use ES-DH as well that do not have the problems of SS. Moreover, as
I originally indicated, SS can be used safely, you just have to choose
a larger group.

I think you're overstating the amount of implementation complexity. I 
estimate
it as being no more than a day or two's work.
 
Have you actually tried it?
Not yet. It's my estimate based on triangulating between the effort
to do DH in SSL and the original effort to do PKCS-7 with RSA. 

 It's a lot more than a day or two's work, and as
I've mentioned before once you've got it all going there's no guarantee,
because of the complexity, that your version will interoperate with anyone
elses version.
Yes, but we expect to publish examples, so I'm not really that concerned
about this issue. 

Just as a data point, in the implementation I have the use of Elgamal for key
transport actually required zero time, it's a heavily object-oriented design 
so
throwing an Elgamal object at key transport works just as well as throwing an
RSA object at it.  At the moment I've actually had to put in special code to
disable Elgamal for key transport, so I guess you could say it'd take a
negative amount of code to implement because I'd have to delete the code which
disables it.  That's got to be fairly conclusive proof that the implementation
overhead is minimal.
I didn't say the ElGamal overhead wasn't minimal. I said that I didn't
consider the DH overhead prohibitive. Implementation complexity is
always a concern, but it's not the only concern.

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