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: Wed, 30 Jan 2002 22:39:51 +0100
To: Blair Dillaway <blaird@microsoft.com>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, reagle@w3.org
Cc: xml-encryption@w3.org
Message-id: <3113076705.1012430391@localhost>
Hi Blair,

--On Mittwoch, 30. Januar 2002 10:18 -0800 Blair Dillaway 
<blaird@microsoft.com> wrote:

> First, we should be clear that ECB-mode encrypting the IV does not
> prevent substitution attacks. I can replace the ECB-encrypted octets and
> the recipient will use the wrong IV on decrypt.  The only difference
> between this and a clear-text IV is that the attacker can't control what
> IV value is actually used.

No, that attack makes no sense. The attack against an unencrypted IV is 
that the attacker can decide which bits of the first plaintext block are 
inverted. If the attacker substitutes or modifies the encrypted IV, 50% of 
the bits of the first plaintext block are toggled.

> Second, I believe the primary use of XML Enc will be to encrypt XML.
> Altering the IV to twiddle the bits in the first block of encrypted XML
> will result in invalid XML in almost every case.  In some corner cases,
> it could result in an unexpected tag name or possible a scrambled first
> word in a text string.  These amount to potential DOS attacks, but will
> not cause an app to misbehave in some insecure manner controllable by
> the attacker.

Encrypting XML does not necessarily mean encrypting Elements. Imagine you 
encrypt the _content_ of the following Element:

<TransferAmount>    1 EUR</TransferAmount>

If the attacker can make a good estimation about the plaintext, he can 
_very_ easy change it so that it decrypts to

<TransferAmount>99999 EUR</TransferAmount>

Such a modification in the IV does _not_ break the parsing process after 
decryption. And even if we talk about Element encryption you can imagine 
(given a block cipher with 128 bit block length) some strange content 
models where important content is vulnerable to such an attack.

> Third, if someone is concerned about IV substitution attacks then we
> have a defined mechanism (XML Sig) for protecting the integrity of the
> IV and other data in the XML document.  Many apps do have requirements
> for protecting the overall integrity of their XML docs and they
> shouldn't be required to also encrypt IVs.

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!

And - if we look how people/developer/users use cryptography in practise, 
many think the following way: "If I use a block cipher and an attacker 
modifies the ciphertext, the plaintext will look completely different and 
I'll detect that." That's right. But if the attacker changes the IV, the 
application does _not_ detect that and the plaintext can be modified in a 
defined manner.

> So let's give apps the flexibility to: 1) include the IV in the clear
> (REQUIRED); 2) include the IV in the clear and apply integrity
> seals(OPTIONAL); 3) ECB-mode encrypt the IV(OPTIONAL).
>
> Blair
>
> P.S. I have also pinged a couple of cryptographers about this issue and
> the response was a uniform - "Why, what are you gaining?".

Simply offer them to have a look into "Handbook of applied cryptography". 
Then they'll see.

>
> -----Original Message-----
> From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]
> Sent: Monday, January 28, 2002 8:52 PM
> To: reagle@w3.org
> Cc: Christian Geuer-Pollmann; Dan Lanz; xml-encryption@w3.org; Blair
> Dillaway
> Subject: Re: Encrypting the IV - again. Was: Re: nonce length
>
>
> Hi,
>
> Last week I was at the IEEE 802.11 meeting in Dallas, particularly
> 802.11 Task Group i, which is working on security. I took the
> opportunity to ask several professional cryptographers about this. One
> suggested the same idea as I started to describe the problem, all the
> others supported encrypting the IV except one who declined to make any
> spur of the moment recommendations.
>
> Based on that, I'm in favor of going for ECB encrypting the IV.
>
> Donald
>
> From:  Joseph Reagle <reagle@w3.org>
> Message-Id:  <200201282254.RAA14246@tux.w3.org>
> Organization:  W3C
> To:  Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>,
>             "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
> Date:  Mon, 28 Jan 2002 17:54:47 -0500
> Cc:  Dan Lanz <lanz@zolera.com>, xml-encryption@w3.org,
> blaird@microsoft.com
> References:  <2942038760.1012259353@crypto>
> In-Reply-To:  <2942038760.1012259353@crypto>
>
>> On Monday 28 January 2002 17:09, Christian Geuer-Pollmann wrote:
>>> Well, it seems to me that I do not need obvious facts to introduce
>>> necessary changes into the spec but well-known names ;-((
>>
>> Hi Christian, I'm not advocating that necessarily, nor that we just
>> need a
>> reference in order to accept it. In fact, I'm not opposed to encrypting
> the
>> IV. I'm just saying that I prefer that *this* WG not take it upon
> itself to
>> introduce a "new mode". I'm most comfortable if the issue has
>> been addressed by others and it's been vetted/discussed/standardized,
> etc.
>> That's that.
>>
>> So, what do others people think? Should we encrypt the IV? (If so,
>> we'll do
>> it.)
>>
>> --
>>
>> Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>> W3C Policy Analyst                mailto:reagle@w3.org
>> IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
>> W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
>
>
Received on Wednesday, 30 January 2002 16:39:40 GMT

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