[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Diffie-Hellman
Hugo,
The requirement for "perfect forward secrecy" was discussed as one of many
criteria for IKMP. There was no agreement on the new criteria identified at
the meeting. Please do not push so hard on just one aspect of the overall
design before we prioritize the criteria. Most of the proposals at this week's
meeting claimed support for perfect forward secrecy so this is not a
discriminating criteria. By the way, what did the "G" for good mean in our
comparison matrix for your MKMP proposal?
I also do not agree with your conclusion that perfect forward secrecy implies a
requirement for Diffie-Hellman. Not being a cryptographer by trade it would be
useful if someone would provide a better description of this requirement and
it's implications.
A Diffie-Hellman (D-H) key exchange is a leading contender for use as a
baseline algorithm within IKMP given the number of proposals that contained D-
H. Performance of D-H and any other proposed key exchange needs to be examined
as part of our groups evaluation of techniques.
Paul
_______________________________________________________________________________
Subject: Diffie-Hellman
Author: hugo@watson.ibm.com@INTERNET
Date: 12/9/94 10:29 AM
Dear IPSEC-ers, (see questions at the bottom)
It seems that if there was something agreed about key management in
this IETF is that we require perfect forward secrecy (in particular,
the exposure of two parties private keys should not expose past or future
traffic between these two parties to passive attacks).
The practical significance of this decision is that we are going to build
the key exchange mechanism based on Diffie-Hellman. Since I believe that
nobody wants to leave this key exchange vulnerable to active
(man-in-the-middle) attacks it actually means that we are going to implement
authenticated DH exchange.
This is a crucial decision of this group. It means that we want to provide
very high security (which is great considering that key management is the
foundation of any security mechanism) and we are willing to pay
the computational price. The later involves six long exponentiations, at least
for parties that exchange their first key.
Some careful optimizations are possible (e.g., some of the exponentiations
performed off-line) but the overall computation cost is not negligible.
It would be nice to close this issue over this list such that we can say
that this is the IPSEC group DECISION and not just the opinion of several
IETF attendees.
The questions are:
1) is there any opposition to this agreement? For example, well-identified
scenarios where this is infeasible?
2) if you have experimental data on the performance of DH exponentiation
please share it with the group. It may help tune the protocol decisions.
PLEASE SPECIFY: h/w and s/w platform, length of modulus (and length of
exponent if different than modulus size) and, if possible, the
software implementation used (RSAREF, PGP, etc.).
Please give numbers for a SINGLE exponentiation (or otherwise specify
what are the numbers for)
(I heard, from people in the IETF, performance numbers that on similar
platforms varied up to 10 times!)
Thanks, Hugo