[3380] in cryptography@c2.net mail archive
Re: Fwd: Re: r.e. quality of IDEA...
daemon@ATHENA.MIT.EDU (Eric Young)
Fri Sep 25 14:50:38 1998
Date: Fri, 25 Sep 1998 17:18:54 +1000 (EST)
From: Eric Young <eay@cryptsoft.com>
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
cc: Steve Bellovin <smb@research.att.com>, perry@piermont.com,
Rodney Thayer <rodney@tillerman.nu>, cryptography@c2.net
In-Reply-To: <199809242100.VAA10462@orchard.arlington.ma.us>
On Thu, 24 Sep 1998, Bill Sommerfeld wrote:
> Presuming non-brain-dead hardware design, you still need to load the
> 56-bit key into the device every time you change keys, but that's
> presumably not going to be too much more expensive than pushing packet
> data into the device..
If we are talking about hardware, or limited memory software, the
functionality will have to be able to handle lots and lots of keys.
Assuming it has n expanded keys in the hardware/limited memory, it just
becomes a caching issue, where the general tendancy for data to be occuring in
bursts would mean that key setup would not be called on each packet.
Even if the software managed hardware key contexts, I do no think this would
be hard. If you are getting a %90 hit rate on the expanded keys, that reduces
the impact of key setup to 1/10. This sort of stuff is easy to code.
People should be able to measure packet source/destination statistics now, an
be able to calculate some interesting number on how big a cache would be
needed to keep the hit rate at > %90.
eric
