[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new second mandatory IPsec cipher
>>>>> "Rodney" == Rodney Thayer <rodney@ssh.fi> writes:
Rodney> At 06:02 PM 7/13/99 +0000, Sandy Harris wrote:
Rodney> After you consider all the heavy lifting required for
Rodney> IPsec/IKE, I don't think Blowfish setup time is really an
Rodney> issue. I also don't buy the "it takes a lot of memory per
Rodney> context" argument, myself, but there are memory-challenged
Rodney> implementations where this is an issue.
Expanding on what Steve Bellovin already said: if you take a system
with a crypto accelerator, as opposed to one that does the whole job
in software, the argument "memory is cheap" is no longer valid.
The issue isn't so much the price of the memory -- though that's often
SRAM which is neither as cheap nor nearly as dense as DRAM. The
bigger issue is that accelerator ASICs have severe limits on the
amount of keying material they will keep on-board.
For example, the chip I'm currently using keeps keying material in a
"context" which is identified by an 11 bit number. It takes two per
IPsec connection. So if you have more than 1000 SA sets, you have to
treat the on-board context as a cache and page the keying material in
from host memory on a miss. In the case of Blowfish, the cost of such
a miss would be vastly LARGER than the cost of encrypting a typical
packet, so the throughput penalty would be significant.
In the case of the AES algorithms, agility was an explicit
requirement. Similarly, the other alternatives that were mentioned
seem to do a reasonable job, either with low key setup time or with
modest expanded key schedule sizes.
So I would rule out Blowfish. I'd also rule out IDEA because of
patent issues. An AES finalist would be a good choice, provided it's
one of the ones that are unconditionally free of intellectual property
issues. (Contrast MARS, which will apparently be restricted unless
it wins the AES competition.)
paul
References: