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

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
>testing.
>
>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.
>
>Blair
>
>-----Original Message-----
>From: Christian Geuer-Pollmann
>[mailto:geuer-pollmann@nue.et-inf.uni-siegen.de] 
>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
>as 
>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
>that 
>XML is not free-choosen text, but restricted by some means.
>
>If we do something like encrypting the IV, it costs us absolutely
>nothing 
>(but 1 block cipher algo execution), but it removes us one potential
>flaw.
>
>Yes, I agree that we say: "We only provide the security service 
>'confidentiality' and do _not_ provide 'integrity'. The user has to use
>XML 
>Signature for integrity." But in this case, I think it makes 
>cryptographically sense to add something like this.
>
>Christian
>
>--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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:19 GMT