W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2001

Re: Encrypting IV in ECB

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Sun, 25 Nov 2001 23:56:37 -0500
Message-Id: <200111260456.XAA0000006355@torque.pothole.com>
To: "XML Encryption WG" <xml-encryption@w3.org>
I'll suggest added text on this.

From:  "Blair Dillaway" <blaird@microsoft.com>
Message-ID:  <AA19CFCE90F52E4B942B27D42349637902CDCDE7@red-msg-01.redmond.corp.microsoft.com>
To:  "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de>,
            "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc:  "XML Encryption WG" <xml-encryption@w3.org>

>I agree with Don on this.  Lets not start adding in IV encryption modes.
>I disagree with the assertion doing this is a trivial change.  It will
>end up creating quite a bit more work for implementors and interop
>The issue Christian describes below is already dealt with through the
>use of the optional NONCE value.  By placing a NONCE of length larger
>than the alg block size, manipulating the IV can only cause the NONCE to
>decrypt incorrectly.  It will not allow one to manipulate the decrypted
>value of the original plain-text.
>-----Original Message-----
>From: Christian Geuer-Pollmann
>Sent: Saturday, November 10, 2001 4:47 AM
>To: Donald E. Eastlake 3rd
>Cc: XML Encryption WG
>Subject: Re: Encrypting IV in ECB
>Hi Donald,
>I think that other standards do not encrypt such higly structured data
>we do. For example, given a schema that allows only particular attribute
>values like here:
><a v='1'/>
>If we encrypt something like this, imagine the v attribute can only have
>the values '1' and '0' by the schema. In such a case, the attacker knows
>exactly on which part of the IV he has to mess around - our problem is
>XML is not free-choosen text, but restricted by some means.
>If we do something like encrypting the IV, it costs us absolutely
>(but 1 block cipher algo execution), but it removes us one potential
>Yes, I agree that we say: "We only provide the security service 
>'confidentiality' and do _not_ provide 'integrity'. The user has to use
>Signature for integrity." But in this case, I think it makes 
>cryptographically sense to add something like this.
>--On Samstag, 10. November 2001 00:17 -0500 "Donald E. Eastlake 3rd" 
><dee3@torque.pothole.com> wrote:
>> While this doesn't seem like such a bad idea, I'm not aware of any 
>> other standards that do this and I'm not sure we should be the first. 
>> This just seems like another case where you want a message integrity 
>> check or signature inside the encryption.
>> Donald
>> From:  Christian Geuer-Pollmann 
>> <geuer-pollmann@nue.et-inf.uni-siegen.de>
>> To:  XML Encryption WG <xml-encryption@w3.org>
>>> about the use of the IV in block encryption in CBC mode: 
>>> [Menezes/Orschoot/Vanstone] state in Remark 7.16 (integrity if IV in
>>> CBC):
>>>  "While the IV in the CBC mode need not be secret, its
>>>   integrity should be protected, since malicious
>>>   modifications thereof allows an adversary to make
>>>   predictable bit changes to the first plaintext
>>>   block recovered."
>>> Suggestion:
>>> If we encrypt the IV in Electronic Codebook Mode (ECB), we ensure 
>>> that modifications on the bit layer will break decryption of the 
>>> complete block.
>>>  "ALGORITHM is used in the Cipher Block Chaining
>>>   (CBC) mode with a ALGO_KEY_BIT_LENGTH bit
>>>   Initialization Vector (IV). <ADD>The IV is
>>>   encrypted in ECB mode.</ADD> The resulting
>>>   cipher text is prefixed by the
>>>   <ADD>encrypted</ADD> IV."
>>> Does this make sense to you?
>>> Best regards,
>>> Christian
>>> [Menezes/Orschoot/Vanstone] Handbook of applied cryptography, page 
>>> 230
Received on Sunday, 25 November 2001 23:59:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:02 UTC