[3371] in cryptography@c2.net mail archive
Key setup time a real issue for IPSEC? Or not?
daemon@ATHENA.MIT.EDU (Ron Rivest)
Thu Sep 24 16:37:20 1998
Date: Thu, 24 Sep 1998 16:22:36 -0400
From: Ron Rivest <rivest@theory.lcs.mit.edu>
To: smb@research.att.com, cryptography@c2.net
Steve Bellovin says,
" The problem is considerably more complex than that, even for
back-of-the-envelope calculations. The distribution of packet sizes is
quite skewed; last time I looked, about 40% of all packets were ~40
bytes long (http://www.nlanr.net/NA/Learn/packetsizes.html). In an
environment with many conversations with different peers, there will be
a lot of tinygrams, and hence a lot of key-switching. Nor am I
convinced that HTTP 1.1 will change that all that much; while we won't
see as many short packets for circuit open and teardown, we'll still
see lots of ACK packets. ..."
What is the issue we are addressing? Computational overhead? Or latency?
I don't believe that key setup time (a few microseconds) is likely to
be factor in latency...
As for computational overhead, it really *is* the average packet size
that matters, and not the distribution. If you have an average packet
size of n AES blocks, and a key setup takes as much time as encrypting
s blocks, then the total time to encrypt N AES blocks of data (broken
into packets however you like) is
(N/n)(n+s) = N (1 + n/s)
***independent of the distribution of packet sizes***. Once the average
size of a packet is fixed, everything else follows. The distribution
doesn't matter...
So, I still think that the time to encrypt an average size packet (including
time to do key setup) is an interesting figure of merit...
Cheers,
Ron Rivest
