RE: Encrypting the IV - again. Was: Re: nonce length

I whole-heartedly agree with what Fritz and Blair are saying. Sure, changing
some bits in the IV allows one to change corresponding bits in the first
plaintext block. Encrypting the IV still allows (albeit unpredictable) bits
to change in the first plaintext block (as Blair has pointed out), just like
changing bits in the ciphertext block Ci, will (albeit unpredictably) change
bits in the plaintext blocks Mi and Mi+1. 

I believe that the quote from Stallings' book is taken out of context (I
actually use this book for course on Cryptography and Computer Security I
teach at my local University). Stalling's doesn't introduce data integrity
till 5 chapters later.

Also, from the Handbook of Applied Cryptography (Blair and Christian have
pointed to this section but I thought I'd include the relevant text):
"7.16 Remark (integrity of IV in CBC) While the IV in CBC mode need not be
secret, its integrity should be protected, since malicious modification
thereof allows an adversary to make predictable bit changes to the first
plaintext block recovered. Using a secret IV is one method for preventing
this. However, if message integrity is required, an appropriate mechanism
should be used (see Sect. 9.6.5); encryption mechanisms typically guarantee
confidentiality only."

So, integrity protecting the IV works (more generally, integrity protecting
the entire plaintext would also work), but as I mention above, altering
ciphertext block Ci also allows some changes to be made. Thus, we are back
to what Fritz suggested; (paraphrasing) if you want integrity of your
plaintext, use XML DSig to protect the plaintext. Note that this could be a
digital signature or a MAC.

I suggest that no requirements be changed, but that something like the
following be added to the Security Considerations section:
"Modification of the IV by an attacker allows predictable bit changes to be
made to the first plaintext block upon decryption. Similarly, modification
to ciphertext block Ci causes plaintext blocks Mi and Mi+1 to be altered
upon decryption. As always, if integrity of the plaintext is desired, then
one should use an appropriate algorithm from XML DigSig computed over the
plaintext."

Mike 

-----Original Message-----
From: Fritz Schneider [mailto:fritz@cs.ucsd.edu]
Sent: Wednesday, January 30, 2002 7:07 PM
To: Christian Geuer-Pollmann
Cc: Blair Dillaway; Donald E. Eastlake 3rd; reagle@w3.org;
xml-encryption@w3.org
Subject: RE: Encrypting the IV - again. Was: Re: nonce length


On Wed, 30 Jan 2002, Christian Geuer-Pollmann wrote:

> That's right. If the application has the requirement for integrity,
> XML Signature SHOULD be used. Encrypting the IV does not guarantee the
> integrity, it's not signcryption. I never promised that. But - shall
> we really use some sub-optimal solution? Transfer the IV unencrypted
> even if the vulnerabilities are obvious? I'd say no!

	I'd say yes. Consider the following observation:

 * If the user IS concerned about integrity then a MAC or digital
   signature must be used because an encrypted IV is not sufficient.
   So the encryption of the IV will be extra work that gains the user
   nothing -- they're already getting a much better integrity guarantee
   from their MAC or signature.

 * If the user IS NOT concerned about integrity then the encryption
   of the IV is extra work that gains the user nothing (because they
   don't care about integrity).

Any way I look at it it seems to me that encrypting the IV is superfluous.

-- fritz