Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IPsec] IV in ESP packets for AES-CBC and AES-CTR methods



The following sentence present in RFC 3602 creates some doubts whether IV in each packet is mandatory or not?

"Including the IV in each datagram ensures that decryption of each
 received datagram can be performed, even when some datagrams are
 dropped, or datagrams are re-ordered in transit."

Thanks
-ns murthy

At 08:00 PM 5/11/2009, Tero Kivinen wrote:
ss murthy nittala writes:
> Is it required for IV to be randomly generated for each ESP packet in
> case of AES-CTR and AES-CBC methods?
>
> AES-CTR:My understanding is that IV is to be generated randomly for
> the first packet.For each new outgoing packet increment IV and use it.

From RFC3686:

   The AES-CTR IV field MUST be eight octets.  The IV MUST be chosen by
   the encryptor in a manner that ensures that the same IV value is used
   only once for a given key.  The encryptor can generate the IV in any
   manner that ensures uniqueness.  Common approaches to IV generation
   include incrementing a counter for each packet and linear feedback
   shift registers (LFSRs).

I.e. it MUST be unique, but there is no other requirements for it.
Incremental counter is one commonly used method.

> AES-CBC:Is it required for IV to be randomly generated for each of
> the outgoing ESP packets?In any case i think the packet shall include IV.

From RFC3602:

   The IV field MUST be the same size as the block size of the cipher
   algorithm being used.  The IV MUST be chosen at random, and MUST be
   unpredictable.
...
   To avoid CBC encryption of very similar plaintext blocks in different
   packets, implementations MUST NOT use a counter or other low-Hamming
   distance source for IVs.

I.e. it MUST be unpredictable, i.e. randomly generated is good. Using
the final ciphertext block of the previous message is NOT acceptable.
--
kivinen at iki.fi



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.