by mail.netbsd.org with SMTP; 20 Jul 2000 12:23:56 -0000
 via SMTP by mailo.vtcif.telstra.com.au, id smtpdvmuF4_; Thu Jul 20 22:23:05 2000
 via SMTP by localhost, id smtpd0xDUmd; Thu Jul 20 22:22:33 2000
          by balrog.supp.cpr.itg.telecom.com.au (8.8.4/8.8.4) with ESMTP
	  id WAA27073; Thu, 20 Jul 2000 22:22:31 +1000
Message-Id: <200007201222.WAA27073@balrog.supp.cpr.itg.telecom.com.au>
From: Simon Burge <simonb@netbsd.org>
To: sommerfeld@orchard.arlington.ma.us
Cc: tech-security@netbsd.org, tech-net@netbsd.org, tech-kern@netbsd.org
Subject: Re: IPsec performance 
In-Reply-To: Your message of "Thu, 20 Jul 2000 08:12:56 -0400 "
	<20000720121301.EE5E82A1B@orchard.arlington.ma.us> 
Date: Thu, 20 Jul 2000 22:22:30 +1000

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?)...

Simon.