[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Son-of-IKE Performance
As background to the discussion, I thought it might be worth
looking at performance of the various IKE replacements.
The following table summarizes the performance behavior of
the major proposals as far as I can make out.
I've also added TLS for comparison.
Protocol Initiator Responder Latency
------------------------------------------------
IKEv2 1 signature 1 signature 2 RTT
1 verify 1 verify
1 DH agree 1 DH agree
IKEv2 1 signature 1 signature 3 RTT
(DoS mode) 1 verify 1 verify
1 DH agree 1 DH agree
SIGMA 1 signature 1 signature 1.5 RTT [1]
1 verify 1 verify
1 DH agree 1 DH agree
SIGMA 1 signature 1 signature 2.5 RTT [1]
(DoS mode) 1 verify 1 verify
1 DH agree 1 DH agree
JFK(normal) 1 signature 1 signature 2 RTT
2 verifies 1 verify
1 DH agree 1 DH agree
JFK(PFS)[2] 1 signature 2 signatures 2 RTT
2 verifies 1 verify
1 DH agree 1 DH agree
TLS (RSA)[3] 1 signature 1 decryption 2 RTT
1 RSA encrypt 1 verify
TLS (PFS)[3] 1 signature 1 signature 2 RTT
1 verify 1 verify
1 DH agree 1 DH agree
Notes:
[0] I'm ignoring the following computational costs since
they're more or less constant across protocols and are
usually cheap.
Digests, symmetric encryption, and PRFs.
Certificate verification (not cheap if DSS)
All of the PFS modes require an additional g^x mod p.
[1] I'm dubious about the value of this. As Phill Hallam-Baker
argues, you'd probably want to use a 4-message handshake anyway.
[2] In JFK, PFS mode is incompatible with DoS protection.
[3] Note that TLS has an anonymous client mode which is even
faster: 1 RSA encrypt on the client and 1 RSA decrypt
on the server.
[4] Here are some approximate timings for the various operations
(measured on a Celeron 300). All moduli are 1024-bit.
RSA private key op 30 ms
RSA public key op 2 ms
DH key agree (1024-bit X) 100 ms
(256-bit X) 25 ms
DSA signature 17 ms
DSA verify 21 ms
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
http://www.rtfm.com/
Follow-Ups: