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

Re: IV (some input for you)

From: Joseph Reagle <reagle@w3.org>
Date: Mon, 14 Jan 2002 16:14:15 -0500
Message-Id: <200201142114.QAA11571@tux.w3.org>
To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>, XML Encryption WG <xml-encryption@w3.org>
Cc: Tom Gindin <tgindin@us.ibm.com>
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

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

[1] (Unfortunately on the xmldsig list by mistake)

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.


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 Monday, 14 January 2002 16:14:19 UTC

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