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

Re: Granularity of authentication in swIPe




>From kent@BBN.COM Fri Jun 24 15:46:51 1994
>Ashar,
>
>	The ability to use the last block as an IV varies depending on
>the crypto interface.  Some implementations allow it, others don't.
>You don't want to hold up a packet waiting for the requisite
>precursors to arrive, since that would violate IP and would kill
>applications like packet voice and video.  

I didn't intend the decrypt routines to ever wait for
pre-requisite packets to arrive.

>So, if you don't carry
>an IV on each packet, you run the risk that out of order arrival 
>and/or packet loss will cause problems.

What I meant was that the last block would be in the "IV" field
and carried in every subsequent packet after the first one (until
rekey time anyway).

If the packets arrived in sequence (and the crypto hw supported
streaming of data) there would be no need to reload the IV.
This would be the fast path and, assuming orderly delivery,
be the common case as well.

If not, then you are no worse than sending  a new IV in
every packet. If packets are lost or out of order, simply load
the last block (carried in the IV field) as the new "IV" for the
packet. This is what you have to do with a new IV in every
packet approach anyway. Given how CBC works, the packet 
should decrypt properly, no? There is enough information
ine every packet to have it be decryptable independently, since
CBC doesn't keep more state than the last block. Am I missing
something?

Ashar.