> -----Original Message----- > From: Yoav Nir [mailto:y...@checkpoint.com] > Sent: Tuesday, May 12, 2009 3:42 AM > To: ssmurthy.nitt...@freescale.com > Cc: ipsec@ietf.org > Subject: Re: [IPsec] IV in ESP packets for DES and 3DES methods > > 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.
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. > > > 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. 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
