Subject: Re: IPsec performance
To: Simon Burge <simonb@netbsd.org>
From: Steven M. Bellovin <smb@research.att.com>
List: tech-security
Date: 07/20/2000 15:51:41
  by mail.netbsd.org with SMTP; 20 Jul 2000 19:52:05 -0000
	by mail-blue.research.att.com (Postfix) with ESMTP
	id A5E894CE31; Thu, 20 Jul 2000 15:52:00 -0400 (EDT)
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id PAA22844;
	Thu, 20 Jul 2000 15:51:57 -0400 (EDT)
	by smb.research.att.com (Postfix) with ESMTP
	id CC68035DC2; Thu, 20 Jul 2000 15:51:56 -0400 (EDT)
From: "Steven M. Bellovin" <smb@research.att.com>
To: Simon Burge <simonb@netbsd.org>
Cc: sommerfeld@orchard.arlington.ma.us, tech-security@netbsd.org,
	tech-net@netbsd.org, tech-kern@netbsd.org
Subject: Re: IPsec performance 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 20 Jul 2000 15:51:41 -0400
Message-Id: <20000720195156.CC68035DC2@smb.research.att.com>

In message <200007201222.WAA27073@balrog.supp.cpr.itg.telecom.com.au>, Simon Bu
rge writes:
>Bill Sommerfeld wrote:
>
>> The expanded blowfish key is large and takes a while to compute;
>> recomputing it for every packet is almost certainly what kills
>> performance -- expanding the key takes ~520 blowfish block
>> encryptions, equivalent to encrypting a bit over 4kb of data.
>> 
>> The solaris implementation of blowfish for ESP (which is in
>> "solaris-current", not yet in any product) just caches the expanded
>> key in per-SA state; netbsd should do likewise.
>> 
>> Something more sophisticated might be appropriate -- perhaps a
>> *drain()-like routine to reclaim the memory for idle SA's -- but
>> redoing the BF_set_key() on every packet is definitely a bad idea.
>
>Idle question - since blowfish isn't an AES candidate, will its life be
>long enough (in IPsec) to justify the work?  I also don't know off the
>top of my head if any of the AES candidate ciphers have large key setup
>times (MARS?)...

In fact, Doug Whiting, Bruce Scheier, and I wrote a short white paper 
on key agility requirements for IPsec for AES -- see
http://www.research.att.com/~smb/papers/AES-KeyAgile.ps

In answer to your specific question -- MARS and RC6 have long key-setup 
times.  Rijndael is fast; Twofish is pretty fast, and gives you a wide 
range of tradeoffs between key setup time and storage requirements.  
Serpent (the fifth finalist) is sufficiently slow in software that I 
don't think that key setup time is an interesting question.

		--Steve Bellovin