- From: Joseph Reagle <reagle@w3.org>
- Date: Mon, 14 Jan 2002 16:14:15 -0500
- 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 > _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.) 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) http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0018.html 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