[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Preliminary comment skip draft 03
Okay. It was not clear to me that you were using RC4. Of course, position
in the stream must be communicated to deal with out of order delivery.
Russ
______________________________ Reply Separator _________________________________
Subject: Re: Preliminary comment skip draft 03
Author: Germano Caronni <caronni@tik.ee.ethz.ch> at internet
Date: 10/21/95 6:19 AM
Housley, Russ wrote:
> Germano Caronni <caronni@tik.ee.ethz.ch> provided this diagram:
> encrypted part
> +---------------+-----------------------+====+========================+
> |32-bit SKIP SPI|64-bit MI network order|data|8bit next protocol field|
> +---------------+-----------------------+====+========================+
> where MI is the number of bytes that were already encrypted with the
> current Kp.
> Why do you want to limit the MI (a.k.a. IV) to the counter? A random
> number works fine too.
Because I am talking about RC4, a stream cipher. Stream ciphers have the
property that encryption of a (bit|byte|...) is position dependant, but
usually does not depend on the data encrypted before. To use a stream cipher
in IP, where packets may be reordered by the network, you have to know at
which 'offset' of the stream this particular block has been encrypted. Then
you can 'seek' (and cache states) in the stream upon receipt of the packet,
and thus decrypt it.
Additional care has to be taken about denial-of-service attacks asking you to
seeek to say 2^63 in the stream, and about the need for resynchronisation,
which could be done when scheduled keychanges occur.
Do you agree?
Friendly greetings,
Germano