[3377] in cryptography@c2.net mail archive
Re: Fwd: Re: r.e. quality of IDEA...
daemon@ATHENA.MIT.EDU (David G. Koontz)
Fri Sep 25 13:50:48 1998
Date: Thu, 24 Sep 1998 17:34:52 -0700
From: "David G. Koontz" <koontz@ariolimax.com>
To: Steve Bellovin <smb@research.att.com>
CC: cryptography@c2.net
Steve Bellovin wrote:
>
> In message <199809241948.PAA25072@jekyll.piermont.com>, "Perry E. Metzger" writ
> es:
> 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?
A quick look at the source for IDEA shows that the key for IDEA doesn't
require
prescheduling.
16 Bytes x 4,096 = 64K bytes can fit in a chip, too.
Key schedule expansion is associated with SW implementations. If your
encryption
hardware were actually processor based, you could have the permutations
hard
coded for key scheduling. The permutations only eat a handful of
addresses
for each supported algorithm. The Lockheed crypto procssor is an
example of
one with programmable hardware to implement permutations for somewhat
open
ended solutions.
The hard part is keeping track of keys on chip. If its done with
hardware,
the on chip memory is cache, and you might as well make it big enough to
handle
data as well. Why bother? To get an efficient design you end up with a
co-processor specific to some bus or another. If the on chip keys are
managed
by a host, the management overhead is close to the key size, again why
bother?
My inclination is to pass a key when needed. Even given that keys
should not
be left lying around 'en claire', the key decryption time could be
partly hidden
by cleverly positioning the key in whatever passes for a control
protocol.
