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

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

From: Blair Dillaway <blaird@microsoft.com>
Date: Wed, 30 Jan 2002 14:45:28 -0800
Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCEC6@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>, <reagle@w3.org>
Cc: <xml-encryption@w3.org>
I respectfully disagree with you.  You are inventing poorly designed
applications of encryption that support your chosen attack.  Badly
designed applications are open to lots of interesting attacks and the
XML Enc standard can not claim to protect against bad design.

To use your own fictitious case, if I know the app always encodes its
data so the first block is digits, with pre-pended blank padding, and
the remainder a currency indicator, I can cause general havoc by
changing your ECB encrypted IV just as well as altering a plaintext IV.
Whether the V is encrypted or not, many changes will result in an
invalid number, others will result in a valid number that wasn't what
was intended. 

A simple design change  - like encrypting the entire element, or
changing the data encoding - insures I will be able to detect
substitution attacks on the IV.  If I care about DOS attacks I'll add
integrity.  If not, encrypting the IV doesn't offer assured protection
against attack so a high-value application shouldn't rely on it.  

Also, in the real world performance matters. Encrypting and decrypting
IVs in ECB mode isn't free.  The use must be justified by the value
added.  I don't see sufficient value to justify making this a required

And the handbook of applied cryptography certainly doesn't suggest
encrypting the IV is a requirement for use of CBC mode block ciphers -
you might want to re-read Section 7.16.   A secret IV is one method
suggested to protect against attacks on the 1st cipher block, but its
not a panacea.


-----Original Message-----
From: Christian Geuer-Pollmann
Sent: Wednesday, January 30, 2002 1:40 PM
To: Blair Dillaway; Donald E. Eastlake 3rd; reagle@w3.org
Cc: xml-encryption@w3.org
Subject: RE: Encrypting the IV - again. Was: Re: nonce length

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%
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
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
the vulnerabilities are obvious? I'd say no!

And - if we look how people/developer/users use cryptography in
many think the following way: "If I use a block cipher and an attacker 
modifies the ciphertext, the plaintext will look completely different
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
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
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
>             "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 17:46:06 UTC

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