[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: new second mandatory IPsec cipher
In message <Pine.BSI.3.91.990713201635.24672A-100000@spsystems.net>, Henry Spen
cer writes:
>On Tue, 13 Jul 1999, Sandy Harris wrote:
>> I don't think it is for IPSEC, though. Blowfish needs extra
>> setup time on every key change to generate the random s-boxes...
>> Also, since the s-boxes are different for every key, an IPSEC
>> box using Blowfish has to store 4K bytes of s-box material
>> per connection. this would be problematic for some.
>
>There is a time-space tradeoff here: *either* you need extra setup time
>on every key change to recompute the S-boxes, *or* you need a chunk of
>memory for each active key to store them. You don't need both. If you
>decide to opt for the extra memory consumption -- a fairly easy decision
>for most users nowadays, since 4KB of memory costs almost nothing -- then
>the setup time must be paid only at rekeying time, when an old key is
>replaced by a new one. That's fairly infrequent for most users.
>
>> Schneier himself says (p 336 AC II):
>> Blowfish is optimised for applications where the key does
>> not change often ... not suitable for applications, such
>> as packet switching, with frequent key changes...
>
>He's assuming early-1990s memory prices, which (arguably) made it painful
>to store the S-boxes for each connection. That assumption is now invalid,
>so don't take the book as gospel.
The real problem isn't on hosts but on dedicated gateways, especially those
with hardware doing the encryption. Today, you can buy boxes that will
handle thousands of IPsec security associations. Yes, the RAM to hold all
the key schedules is cheap enough. But you can't store them all on-chip,
and you can't move that much data from RAM onto the chip fast enough. Given
typical packet sizes, you'd spend more chip bandwidth loading key schedules
than you would reading and writing packets.
Follow-Ups: