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

Diffie-Hellman Performance



Let me add that careful choice of a secret exponent size commensurate
with the size of the modulus, any underlying subgroup q, and the target
algorithm you are deriving keying material for is also important.  Using
160-bit or 256-bit exponents can be quite reasonable in many cases. 
Especially if the DH exchange at hand is only to provide bits for forward
secrecy purposes. 

Compare this to using, say, a 1024-bit exponent, and things are going to
be relatively zippy.  For example, what purpose does it serve to use
1024-bit parameters if the algorithm you need keying material for is 40-bit
DES? (Hilarie, maybe you could give a pointer to the presentation you
gave at the Dallas IETF meeting on this.)

For routers, servers, and other high-throughput machines, look for
specialized co-processors dedicated to this purpose.  Quite a few
different companies have these in development for release this year and
the economics and market are pulling the market in this direction. Look for
100 connections-per-second or so, including authentication, in the
not-to-distant future.   Besides, compared with all the other delays in
building a connection over the Internet these days, this is a fraction of a
second I'm willing to put up with. (Of course, your mileage may vary...)

Even without the special silicon DH-based key agreement can be
implemented quite efficiently.  Using assembly-language optimized
libraries and keeping your key and group parameter sizes realistic is the
way to go.  Using 2048-bit parameters when 512 bits is more appropirate
is an easy mistake to make in any public-key application if you don't take
the time to understand the attacks on the mechanisms you are using and
the real security requirements and risks for your system.

-John Kennedy
jkennedy@novell.com

>>> Hilarie Orman <ho@earth.hpc.org> 01/05/97 12:44pm >>>
>  You'd be lucky 
>  to see 5 keys exchanged a second with Diffie-Hellman.  Has anyone 
>  measured (or at least estimated) the performance metrics for IPsec 
>  routers (and hosts) to exchange/update keys?  And on total IPsec
>  routing performance, say with a mixture of clear and encrypted links,
>  using various key update intervals. 

Luck has very little to do with it; modulus size and implementation are
more relevant.  Also key lifetime and number of different SA's needed
per
unit time.

You can do much better than 200 msec for a reasonably secure DH, but
there's
no question that it imposes a severe computational burden, and you also
need
to add the cost of authentication.  In cases where the participants are
static,
it shouldn't be necessary to do DH very often.  In the case of a server
machine establishing hundreds(?) of different client connections per
second,
the authenticated keying might well swamp the machine, leading to need
for
a second processor.

Hilarie