[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP with stream ciphers
On Tue, 15 Apr 1997, Rodney Thayer wrote:
> Am I correct this stream offset is a 32-bit animal not a 64-bit animal?
The first draft for stream ciphers specified a 64 bit offset. The second draft
specifies an offset of 32 or 64 bits, with 32 bits recommended.
> We need 8 byte IV's for DES and 3DES, right? Not 24 bytes for 3DES?
DES requires a 64 bit IV, but for ESP a 32 bit folded IV is often transmitted.
Early 3DES drafts require a 64 bit IV (outer, not inner).
> Why do we need a stream offset anyway? I assume that, since it's a stream,
> the data order is significant,
> and if you get packets out of order you have to be careful how you feed
> them into the decryption
> logic. But wouldn't the IP header give you enough information to detect
> out-of-order anyway?
> Also, regardless of how you determine stream offset, what are you going to
> do when you get
> bytes out of order?
The ciphers are stream ciphers, but IP has no concept of streams. Stream
offsets are needed by stream ciphers for the same reason that IVs are needed
by chained block ciphers: so that packets can be decrypted even if they are
received out of order.
Using the ip_id field to detect out-of-order packets is problematic for a
couple of reasons. First, this value is unique for all IP packets sent by a
host, so on any given connection it is not necessarily contiguous. This
complicates window management. Second, this is a 16-bit value initialized
from the system clock, so you would have to deal with wraparound.
Given an out-of-order packet with a stream offset, what you do depends on the
cipher. For SEAL, the pad can be computed directly. RC4 can move forward or
backward in the key stream; cacheing state can save work here.
Norm
Norman Shulman Secure Computing Canada
Systems Developer Tel 1 416 813 2075
norm@border.com Fax 1 416 813 2001
Follow-Ups:
References: