Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods

From: Yoav Nir <[email-masked]>
Date: Tue, 12 May 2009 10:41:49 +0300

WARNING: contains banned part

Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods
From: Yoav Nir <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 12 May 2009 10:41:49 +0300

On Tue, 2009-05-12 at 10:05 +0000, ss murthy nittala wrote:
> Hi
> 
> Thanks for the clarifications regarding IV usage for AES methods.
> 
> RFC 2405 (DES) in its implementation note says
> 
> "Common practice is to use random data for the first IV and the last 
> 8 octets of encrypted data from an encryption process as the IV for 
> the next encryption process; this logically extends the CBC across 
> the packets.It also has the advantage of limiting the leakage of 
> information from the random number genrator. No matter which mechnism 
> is used, the receiver MUST NOT assume any meaning for this value, 
> other than that it is an IV."

This was common practice at the time. Random numbers were considered a
scarce resources then, so using the last block of ciphertext was a close
enough approximation. Today random data is not scarce (operating systems
provide good enough random), so it's no longer recommended.

> But towards the end of the RFC, it says
> 
> "For the first block of plaintext, though, the IV takes the place
>   of the previous block of ciphertext.  If the IV doesn't differ
>   much from the previous IV, and the actual plaintext block doesn't
>   differ much from the previous packet's, then the effective
>   plaintext won't differ much, either.  This means that you have
>   pairs of ciphertext blocks combined with plaintext blocks that
>   differ in just a few bit positions.  This can be a wedge for
>   assorted cryptanalytic attacks."
> 
> What is RFC suggesting here?Anyway we can not avoid the possibility 
> of successive plain packets being identical atleast partially.
> Is Random number for IV a must or it is ok to get it from the 
> previous encrypted packet for DES?
> 
> What are the latest observations?
> 
> I also want know the same regarding 3DES.

RFCs are more about interoperability than operational security. The
method of generating the IV does not affect interoperability, so you'll
often see it discussed in "Security Considerations" sections without the
RFC 2119 terminology. Random numbers are better than using the previous
ciphertext block, and this is true for DES, 3DES, AES or any block
cipher.

Email secured by Check Point

---

From: "Scott Fluhrer" <[email-masked]>
Date: Tue, 12 May 2009 07:59:23 -0400

> -----Original Message-----
> From: Yoav Nir [mailto:[email-masked]] 
> Sent: Tuesday, May 12, 2009 3:42 AM
> To: [email-masked]
> Cc: [email-masked]
> > the next encryption process; this logically extends the CBC 
> across the 
> > packets.It also has the advantage of limiting the leakage of 
> This was common practice at the time. Random numbers were 
> considered a scarce resources then, so using the last block 
> of ciphertext was a close enough approximation. Today random 
> data is not scarce (operating systems provide good enough 
> random), so it's no longer recommended.

More than recommended; after the time RFC 2405 was written, it was
recognized that predictable IVs can be used as a part of an attack if the
attacker can inject his own traffic into the plaintext stream (and there are
scenarios where that is plausible).

Now, it's not essential that the IV be actually random; another possibility
would be to use the same key used to encrypt the plaintext to form the IV as
well (by taking a predictable value and encrypting that).  That makes it
unpredictable to someone who doesn't know the key, and that's what we care
about.

> > What is RFC suggesting here?Anyway we can not avoid the 
> possibility of 
> > successive plain packets being identical atleast partially.
> > Is Random number for IV a must or it is ok to get it from 
> the previous 
> > encrypted packet for DES?
> > 
> RFCs are more about interoperability than operational 
> security.

Well, no, the RFCs for security protocols are, in part, about security (and
yes, they can't cover every misimplementation possible, they at least make
an attempt).  RFC 2405 would have forbidden reusing the ciphertext block,
had it been recognized for a weakness at the time.

>           The method of generating the IV does not affect 
> interoperability, so you'll often see it discussed in 
> "Security Considerations" sections without the RFC 2119 
> terminology. Random numbers are better than using the 
> previous ciphertext block, and this is true for DES, 3DES, 
> AES or any block cipher.

In CBC mode.  Other modes (say, counter or GCM) have different requirements
for IV generation.

-- 
scott