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

Re: IV (some input for you)

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Mon, 14 Jan 2002 22:44:24 +0100
To: reagle@w3.org, XML Encryption WG <xml-encryption@w3.org>
Cc: Tom Gindin <tgindin@us.ibm.com>
Message-ID: <1730949601.1011048264@clouseau>
On Montag, 14. Januar 2002 16:14 -0500 Joseph Reagle <reagle@w3.org> wrote:
> On Monday 14 January 2002 15:31, Christian Geuer-Pollmann wrote:
>> <CITE>
>> 7.13 Algorithm CBC mode of operation: Properties of the CBC mode of
>> operation:
>>
>> 1. Identical plaintexts: identical ciphertext blocks
>>    result when the same plaintext is enciphered
>>    under the same key and IV . Changing the IV ,
>>    key, or first plaintext block (e.g., using a counter
>>    or random field) results in different ciphertext.
>> </CITE>
>>
>> This means even if you use the IV in counter mode (1st IV = 0x00000001,
>> 2nd IV = 0x00000002) and not as a randomized array, a dictionary attack
>> _IS_NOT_POSSIBLE_.
>
> Does this mean?
> 1. You still advocate it be a random number? (If I understand correctly,
> the answer is "yes" because it mitigates "Type B" attacks in which
> someone  can tweak the underlying plaintext -- though we can also say
> even this does  guarantee authenticity/integrity.)

No, it does not matter whether you use a random number or a counter, it 
must only be unique. The integrity can only be guaranteed if you keep the 
IV secret (by encrypting it) or - of course - if you have a hard integrity 
check like XML Signature.

> 2. Did I understand on the call correctly (and capture in the minutes)
> that  you no longer argue with the position expressed by Tom that the
> *only*  block receiving more entropy from the use of a nonce is the
> immediately  following one? Instead, you know believe that the nonce and
> IV are equivalent to that end, but there's no need for redundancy?

I strongly argue _not_ to use a prepended nonce because it makes no sense.

Let's make an experiment: You use a NULL-IV containing only zero bits and 
you prepend your plaintext with a Nonce (random or counter) with the length 
of the block length. Due to the fact that you use a NULL-IV, you don't 
transport it. What I have outlined here _is_ simply the CBC with an IV 
without Nonce. The "Nonce" that I prepended to the plaintext had been 
encrypted and the result was the IV. Nonce and IV are interchangable.

But we must use one of them, either IV or Nonce, and why invent something 
that no other crypto expert uses or recommnds? Nonces (prepended bytes 
before the plaintext) are not used in symmetrict ciphers. They use IVs. Dot.

Both, Nonce and IV have an impact on the ciphertext (see the citation on 
top of the message). But Nonce and IV provide (for confidentiality) exactly 
the same thing: They bring the feedback loop in CBC into a good state.

But the Nonce does not address the integrity problem. You always can change 
(at least) one octet of the plaintext without being detected. Encrypting 
the IV would crash the complete block without letting the attacker choose 
WHICH bit will be toggled.


Christian


> So if we use a Nonce which length is (blocklength - 1), we have the
> situation that the block containing the first plaintext octet (and the
> preceding blocklength-1 nonce octets) gets a higher entropy, but ONLY this
> block gets a higher entropy. All following blocks to not take advantage of
> this nonce. Additionally, the first plaintext octet is vulnerable to
> malicious modification.
>
> [TG] I don't think this follows.  In particular, if you modify plaintext
> and you're using both CBC and PKCS-5 padding, you'll probably break the
> padding (probability slightly less than 254/255) and cause decryption to
> fail.  This is true for any block encryption using both CBC and PKCS-5
> padding.  Also, for any block encryption using CBC you'll modify ALL
> subsequent plaintext.
Received on Monday, 14 January 2002 16:47:55 GMT

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