[3391] in cryptography@c2.net mail archive
Re: quality of IDEA...
daemon@ATHENA.MIT.EDU (Rieks Joosten)
Mon Sep 28 18:39:23 1998
From: "Rieks Joosten" <r.joosten@pijnenburg.nl>
To: perry@piermont.com, Steve Bellovin <smb@research.att.com>
Date: Mon, 28 Sep 1998 09:12:40 +0100
Reply-to: r.joosten@pijnenburg.nl
CC: Rodney Thayer <rodney@tillerman.nu>, cryptography@c2.net
In-reply-to: <199809242016.QAA01230@postal.research.att.com>
> > > 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.
Memory chips are cheap as compared with crypto chips, primarily
because of quantities. So RAM manufacturers (as opposed to crypto
chip designers) can:
- easily optimize their chip design - engineering cost is no issue.
- set up dedicated RAM manufacturing sites, using the latest
technology.
- drop prices relatively quickly.
So really, you cannot compare the price for a RAM with that of a crypto
chip.
> 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).
Generally, you would be able to get a key schedule out of RAM as you
need it. This would be the preferred way to go when a lot of subkey
material needs to be stored. For IDEA decryption however, you could
think about calculating the subkeys 'on the fly', except for those
that are hard to calculate that way (the multiplicative inverses),
which you could store in RAM or registers, whatever turns out to be
smallest.
> 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?
Let's see: 4096 x 64 bits for the keys, and say an additional 7 equally
large subkeys would be 32k x 64 bit memory. No (technical) problem.
There may be a marketing problem, in that such chips are not going go
be as cheap as memory chips. Also, the more room you need on chip for
(sub)key storage, the less room you have for other (crypto) logic.
Personally, I prefer the algorithms that can do subkey calculation on
the fly. Such algorithms lead to smaller (=cheaper) chips especially if
you need to keep a lot of keys (and their contexts) on the same chip.
Rieks
------------------------------------------------------------------
Rieks Joosten email: r.joosten@pijnenburg.nl
Pijnenburg Custom Chips B.V. phone: +31 73 6848450
P.O. Box 330 fax : +31 73 6848479
5260 AH Vught, The Netherlands
------------------------------------------------------------------
