W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2002

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

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Thu, 31 Jan 2002 15:03:58 +0100
To: Mike Just <Mike.Just@entrust.com>, xml-encryption@w3.org
Cc: "'Fritz Schneider'" <fritz@cs.ucsd.edu>, Blair Dillaway <blaird@microsoft.com>, reagle@w3.org
Message-id: <3172124026.1012489438@crypto>
Hi Mike,

--On Donnerstag, 31. Januar 2002 08:44 -0500 Mike Just 
<Mike.Just@entrust.com> wrote:

> 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.

Right. That's what I suggested. A modification in the encrypted IV trashes 
the whole number of bits like a modification in a ciphertext block does.

> 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.

It's not taken out of context (page 85/86): "... the opponent is able to 
invert selected bits in the first block of plaintext." It doesn't matter in 
which chapter he formally introduces integrity. This sentence deals with an 
integrity issue.

> 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."

If we move the sentence on how to transport the IV into the appropriate 
subsections (meaning the sections where

http://www.w3.org/2001/04/xmlenc#tripledes-cbc
http://www.w3.org/2001/04/xmlenc#aes128-cbc
http://www.w3.org/2001/04/xmlenc#aes192-cbc
http://www.w3.org/2001/04/xmlenc#aes256-cbc

are described), everything's fine. This is also necessary because having an 
IV defined for all block algorithms would make ne sense because there could 
be custom block algorithms which do not have any IV.


Christian

>
> 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
>
>
>
Received on Thursday, 31 January 2002 09:02:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:07 UTC