[3370] in cryptography@c2.net mail archive
Re: Fwd: Re: r.e. quality of IDEA...
daemon@ATHENA.MIT.EDU (Steve Bellovin)
Thu Sep 24 16:37:11 1998
To: perry@piermont.com
cc: Rodney Thayer <rodney@tillerman.nu>, cryptography@c2.net
Date: Thu, 24 Sep 1998 16:16:02 -0400
From: Steve Bellovin <smb@research.att.com>
In message <199809241948.PAA25072@jekyll.piermont.com>, "Perry E. Metzger" writ
es:
>
> Steve Bellovin writes:
> > The issue is maintaining many IPSEC sessions at the same time, perhaps
> > to different destinations. Given the expansion factor between the
> > key size and the key schedule in many ciphers, it is often infeasible
> > to store key schedules. This is especially true for hardware-based
> > IPSEC devices, where there is a very big incentive to keep all keying
> > material on-board.
>
> Is this really true, in practice? Retail price of 16M of memory is
> now, what, $10-$20? I bet that in even another few hundred k you could
> fit a *lot* of key schedules.
I'll let real hardware geeks take a better stab at this -- but yes, I
do think it's an issue.
First, RAM is not the same as a fast register in the datapath. For
fast cryptographic operations, you need the key schedule sitting in
registers. You can't afford to move things around, either; even DES's
~~100 bytes represents too many cycles for data movement. Can you do
fetch-on-demand (or a cycle or so ahead of demand)? Maybe, though that
requires a really fast memory, too, and perhaps more logic than the
encryption algorithm. It's also hard, I've read, to put too much
memory on the same chip as lots of logic (though I'm wandering *very*
far afield here from anything I really know much about).
It would be interesting to hear from anyone who has actually designed
encryption chips. Could you easily handle many -- say, ~4096 or above --
different key schedules on-chip?
Btw -- there are other scenarios that need really fast key setup, too.
Remember the DEC gigabit DES chip? The first byte of each packet was
a copy of the key encrypted in a per-chip DES key -- you send each
correspondent a copy of the session key that you've encrypted with a
key only you know. It decrypts that block at line speed, then uses
the decrypted session key to handle the rest of the packet.
