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

I have no more to say on this topic and believe this issue has been
adequately discussed. I will support the inclusion of ECB encryption of
the IV as an optional feature.  I will not support this as a required
feature.

Blair

-----Original Message-----
From: Christian Geuer-Pollmann
[mailto:geuer-pollmann@nue.et-inf.uni-siegen.de] 
Sent: Thursday, January 31, 2002 1:21 AM
To: Blair Dillaway; reagle@w3.org
Cc: xml-encryption@w3.org
Subject: RE: Encrypting the IV - again. Was: Re: nonce length


Hi Blair,
hi Joseph,

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

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

You're right. The example given below _is_ a poorly designed
application. 
But it's not impossible that people use schemes like that.

We can't prevent that people shoot themselfes into the knee, but we can 
make the spec as secure as possible. If we encrypt data, we shouldn't
make 
assumptions on how good the underlying content model is, let's assume
that 
people do things that we never thought.

One question is: Do we really want to force people to use a huge and 
complex XML Signature implementation just for ensuring full integrity?
Many 
people _use_ block ciphers (which are only a confidentiality mechanism)
for 
getting also some kind of integrity: If I can read and understand it
after 
decryption, then it's OK. And that's _right_ for all plaintext blocks
but 
the first one.

Like you also described below, if an attacker changes some bits in a 
ciphertext block, each bit in the decrypted plaintext is toggled with a 
probability of 50%. Given that the plaintext is a UTF-8 string, this 
results with a high probability in an invalid UTF-8 string which breaks 
parsing. That's good because it gives some kind of implicit integrity.
This 
works because the attacker cannot make defined changes to the plaintext
but 
changes 50% of the bits.

But - if the attacker changes the IV, he makes defined changes to the
first 
block of plaintext. And it's easy to make a good guess on how such a
change 
must look to not produce invalid UTF-8.


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

DOS is not a problem to me. If an attacker wants that decryption fails, 
he'll do that. And it doesn't matter whether decrpytion or signature 
validation fails.

> 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

> operation.

No, it isn't free. It costs in block cipher operation. The question is: 
Does this really  matter? If I encrypt a huge document, it doesn't
matter. 
If I encrypt many small chunks, it matters. It depends on the
application 
whether these processing costs matter or not. But the same is true for
the 
complete process. Parsing many small chunks of plaintext costs, too. If 
processing power is such a big problem for an application, it should be 
questioned whether XML is the right choice.

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

Remark 7.16 tells that the integrity if the IV should be protected to 
ensure the integrity of the plaintext. And that using a secret IV is a
way 
to achive that. Encrypting the IV in ECB is one way to get a secret IV. 
Prepending it unencrypted to plaintext is not. XML Signature is a good
way 
to ensure integrity. But what do we tell the people who don't want the 
processing overhead of XML Signature (which is much more than encrypting

the IV), but need some kind of implicit integrity from that 'if I can
parse 
it, it's OK'?

Joseph, my suggestion for our spec is the following. Actually, the
sentence

   "The IV is encoded with and before the cipher
    text for the algorithms below for ease of
    availability to the decryption code and
    to emphasize its association with the cipher
    text. Good cryptographic practice requires
    that a different IV be used for every encryption."

is in the section 5.2 about block encryption algorithms in general.
Could 
we move the 'plaintext-IV' stuff from 5.2 which covers _all_ block 
algorithms to 5.2.1 and 5.2.2 which cover the 3DES and AES specifically?

This would simply allow to handle the IV (encrypted or not) for each
block 
algorithm individually. So Blair does not need to change his
implementation 
and people who see the requirement for encrypting the IV can do this
using 
another URI.

Christian

>
> Blair
>
>
>
> -----Original Message-----
> From: Christian Geuer-Pollmann 
> [mailto:geuer-pollmann@nue.et-inf.uni-siegen.de]
> 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% 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 Thursday, 31 January 2002 12:12:16 UTC