[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Diffie-Hellman (note by Hugo)

>Let me second Ashar.  Different users need different levels of
>security.  For those who ask for confidentiality, then I think we need
>to provide strong confidentiality with perfect forward secrecy.  For
>those who ask for just authentication, we need to provide strong
>authentication but secrecy of any sort is not a question.

This is an appealing argument, but it carries the danger that we'll
come up with so many different mechanisms that we either have less
than perfect interoperability, or everybody will have to implement
everything, which means a lot more work and more delay in reaching the
market.

I would much prefer a single scheme (for interoperability) that can
solve the worst case problem, but with "tuning knobs" to speed things
up when less than maximum security is acceptable.

Photuris and similar authenticated Diffie-Hellman schemes can do this
very nicely. For absolute maximum security, the background task that
generates Diffie-Hellman public/private keys and signs them with RSA
could run continuously, soaking up all available CPU time. And each
time a new local DH key is generated, you could renegotiate new
session keys for all of your existing SAIDs.

At the other extreme you could generate a DH key pair and sign it just
once, keeping it "forever" across system reboots. This essentially
collapses into SKIP as I understand it.

Or you could find a happy middle. My point is that a single protocol
CAN meet all of these cases, which is a big interoperability win.

I don't really think the cost of Diffie-Hellman is all that
intolerable.  I used it all last week on my not-blazingly-fast laptop.
It took a few seconds each time, not so long to tempt me to bypass it.
This is a big improvement over last time when I used full-sized (1024
bit) exponents instead of shorter (128-bit) exponents to generate a
56-bit DES key. And that's with plain RSAREF code, which is known to
be at least 2-3x slower than several other widely available modexp
routines. And I'm not yet hiding the first two exponentiations in the
background, which will nearly triple the apparent performance of the
protocol.

In sum: Diffie-Hellman performance is already acceptable in most
cases, near-term performance concerns are better met by varying the
parameters of a single protocol rather than by creating multiple
incompatible protocols, and faster CPUs and improved code and
protocols will eventually moot the DH performance issue anyway.

Phil
Follow-Ups: References: