[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ESP with stream ciphers

Exactly what will this look like?

I guess the current scheme is:

  <8 byte IV>
  <data>

and the new scheme will be:

  <8 byte IV>
  <data>

  -OR-

  <stream offset, a 32-bit number in network order>
  <data>

So...

Am I correct this stream offset is a 32-bit animal not a 64-bit animal?

We need 8 byte IV's for DES and 3DES, right?  Not 24 bytes for 3DES?

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?

At 07:17 PM 4/14/97 -0400, you wrote:
>Norm,
>
>	I agree with Steve Bellovin's suggestion that we should view the IV
>as the beginning of the payload, since each encryption algorithm mode will
>"know" whether an IV is explicitly present, or not, and how big it is, etc.
>This tact was adopted in some other security protocols, e.g., the IEEE SDE
>protocol, while others opted for an explicit IV field.  In an effort to
>simplify the format and minimize optional variable length fields, I'm in
>favor of adopoting Steve's suggestion.  In this vein, a stream cipher
>offset(or an IV for a stream cipher) could also appear as the beginning of
>an encrypted payload.  If there are no objections, I'll plan to make these
>changes to the next rev of the ESP spec.
>
>Steve
>
>
>
>
Follow-Ups: References: