by mail.netbsd.org with SMTP; 20 Jul 2000 08:23:53 -0000
	by mail-green.research.att.com (Postfix) with ESMTP
	id 5C72E1E007; Thu, 20 Jul 2000 04:23:52 -0400 (EDT)
	by postal.research.att.com (8.8.7/8.8.7) with ESMTP id EAA08531;
	Thu, 20 Jul 2000 04:23:30 -0400 (EDT)
	by smb.research.att.com (Postfix) with ESMTP
	id A83BB35DC3; Thu, 20 Jul 2000 03:10:33 -0400 (EDT)
From: "Steven M. Bellovin" <smb@research.att.com>
To: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
Cc: itojun@iijlab.net, tls@rek.tjls.com, 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 03:10:33 -0400
Message-Id: <20000720071033.A83BB35DC3@smb.research.att.com>

In message <20000719103407.D29090@theory.cs.uni-bonn.de>, Ignatios Souvatzis wr
ites:
>On Wed, Jul 19, 2000 at 06:24:05AM +0900, itojun@iijlab.net wrote:
>> 
>> >With 466MHz Celeron CPUs and decent network hardware (3c905B) the most
>> >throughput I seem to be able to force through our IPsec is about 1.5MB/sec
>> >(that's mega *bytes*, not bits).  Though I'm told by several people that
>> >this is not atypical for a software-only IPsec implementation, I don't
>> >understand _why_.
>> 
>> 	see KAME PR 229.
>> 	http://orange.kame.net/dev/query-pr.cgi?pr=229
>> 
>> 	basically, blowfish uses very big intermediate data and we cant
>> 	hold it on the stack.  we endup using static memory pool and
>> 	hence we need spl locks.  we'll try to correct it.
>
>Thats specific to blowfish? What should we used on underpowered machines
>instead?

It would be very interesting for someone to implement Rijndael or 
Twofish -- both are AES candidates, and both are pretty fast in 
software, especially Rijndael.  (AES is the Advanced Encryption 
Standard.  There are five finalists; the winner is supposed to be 
selected in the next few months.  See http://www.nist.gov/aes, I believe.)

		--Steve Bellovin