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