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

Re: nonce length

From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Date: Tue, 08 Jan 2002 16:04:54 +0100
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc: Dan Lanz <lanz@zolera.com>, xml-encryption@w3.org, reagle@w3.org, blaird@microsoft.com
Message-ID: <1188579797.1010505894@clouseau>
But this all works because CBC let's you directly toggle bits in the 
following block without producing decryption errors. My personal wish for a 
tweak would be very simple:

   Always encrypt the IV (of an
   xenc:EncryptedData element
   with a block cipher) in EBC mode !!!

I re-cite [1]:

about the use of the IV in block encryption in CBC mode:
[Menezes/Orschoot/Vanstone] state in Remark 7.16 (integrity if IV in CBC):

  "While the IV in the CBC mode need not be secret, its
   integrity should be protected, since malicious
   modifications thereof allows an adversary to make
   predictable bit changes to the first plaintext
   block recovered."

And now it comes:

   "Using a secret IV is one method for preventing this."

So if we encrypt the IV using the given Content Encryption Key in 
Electronic Code Book (EBC) mode, we achieve this. And hey - EBC is _NOT_ 
bad for encrypting a single block of random data (like an IV).

Using this approach (do not prepend the CBC-encrypted data with the IV but 
with the ECB-encrypted IV), we get rid of this problem _AND_ we get rid of 
this Nonce attribute.

BTW, a nonce (or salt like the UNIX-passwd-people would say or 
time-variant-parameter (TVP) like the ISO people would say) is usually not 
used in symmetric algorithms (like a CBC encryption) but in asymmetric 
functions like a cryptographic hash function (unix password) or RSA 
encryption (RSA-OAEP).

The xenc:EncryptedData/@Nonce did not held any of it's promises. Let's kick 
it away.


Christian


[1] http://lists.w3.org/Archives/Public/xml-encryption/2001Nov/0010.html

--On Dienstag, 8. Januar 2002 09:37 -0500 "Donald E. Eastlake 3rd" 
<dee3@torque.pothole.com> wrote:

> This is a good point... The best solution seems to be to sign the data
> inside the encryption. But we might as well recommend blocksize-1
> length nonces for CBC as that's the best you can do and should certainly
> add enough entropy...
>
> Donald
>
> From:  Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
> Date:  Fri, 04 Jan 2002 14:16:42 +0100
> In-reply-to:  <3C34AB3F.F6F3215B@zolera.com>
> To:  Dan Lanz <lanz@zolera.com>, xml-encryption@w3.org, reagle@w3.org,
>             blaird@microsoft.com
> Message-id:  <836488354.1010153802@crypto>
>
>> Hi Dan,
>>
>> the xenc:EncryptedData/@Nonce attribute like described in the spec is
>> NOT a  fully-working solution against IV-Attacks. Even while using a
>> Nonce, an  attacker can modify encrypted contents without knowing the
>> key if he can  make a good guess about the plaintext. In short, the
>> number of modifyable  bytes is:
>>
>> modifyableByteLength = blockLength - (nonceLength % blockLength)
>>
>> Example AES (blockLength = 16 bytes)
>>
>> nonceLength  |  modifyableByteLength(nonceLength)
>> -------------+-----------------------------------
>>    0        |       16 bytes
>>    1        |       15 bytes
>>    2        |       14 bytes
>>    3        |       13 bytes
>> ...
>>   15        |        1 bytes
>>   16        |       16 bytes
>>   17        |       15 bytes
>>   18        |       14 bytes
>>
>> This attack works because the decryptor has no way to detect that the IV
>> or  bytes inside a complete Nonce block are tampered. (Yes, I know that
>> encryption does not provide integrity, but in the past it was argued
>> that  the Nonce solves the IV-attack problem). In the spec, we have to
>> following  sentence (section 6.3):
>>
>>  "Some encryption algorithms take an initialization
>>   vector (IV) such that an adversary modifying the
>>   IV can make a known change in the plain text after
>>   decryption. This attack can be avoided by securing
>>   the integrity of the plain text data, for example
>>   by signing it, or, for most such algorithms, by
>>   including an algorithm dependent length. A nonce
>>   at least as long as the block for CBC chaining
>>   block encryption algorithms may be adequate."
>>
>> Well, today I've learned that only nonce values of (n * blocklength - 1)
>> are 'secure' and this only if you encrypt an Element (because in this
>> case  only the 1st byte can be modified and this is the '<' sign which
>> MUST be  the first if you have Element content).
>>
>> Example below shows how this looks like; I encrypt the contents of the
>> root  element which is only a Text node (luckily of length = blocklength
>> ;-))) In  the example I changed "1 USD           " to "999.999.999 EUR ".
>>
>>
>> - Plaintext ------------------------------------------------
>>
>> <!-- AES-Key is in hex "000102030405060708090a0b0c0d0e0f"
>> <!-- 1 -->
>> <root>1 USD           </root>
>> <!-- 2 -->
>>
>> - Original ciphertext --------------------------------------
>>
>> <!-- AES-Key is in hex "000102030405060708090a0b0c0d0e0f"
>> <!-- 1 -->
>> <root><xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>> Id="myFirstEncryptedElement" Nonce="32"
>> Type="http://www.w3.org/2001/04/xmlenc#Content">
>> <xenc:EncryptionMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"></xenc:Encryptio
>> nMe thod>
>> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>> <ds:KeyName>Christian Geuer-Pollmann</ds:KeyName>
>> </ds:KeyInfo>
>> <xenc:CipherData>
>> <xenc:CipherValue>xk0dIDXBBtpMGasfZFQXegnju13ya7MMSMZvwBKycKJ+AzhsG7D/dP
>> K6l qy1aRFxzIdIfGON9Zl+
>> prptdMSo+ob76T3CY1bHPQhGjQQmnEA=</xenc:CipherValue>
>> </xenc:CipherData>
>> </xenc:EncryptedData></root>
>> <!-- 2 -->
>>
>> - modified ciphertext --------------------------------------
>>
>> <!-- AES-Key is in hex "000102030405060708090a0b0c0d0e0f"
>> <!-- 1 -->
>> <root><xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
>> Id="myFirstEncryptedElement" Nonce="32"
>> Type="http://www.w3.org/2001/04/xmlenc#Content">
>> <xenc:EncryptionMethod
>> Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"></xenc:Encryptio
>> nMe thod>
>> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>> <ds:KeyName>Christian Geuer-Pollmann</ds:KeyName>
>> </ds:KeyInfo>
>> <xenc:CipherData>
>> <xenc:CipherValue>xk0dIDXBBtpMGasfZFQXegnju13ya7MMSMZvwBKycKJ2GlQRZqnmeu
>> ujj 6zQHGNxzIdIfGON9Zl+
>> prptdMSo+ob76T3CY1bHPQhGjQQmnEA=</xenc:CipherValue>
>> </xenc:CipherData>
>> </xenc:EncryptedData></root>
>> <!-- 2 -->
>>
>> - resulting plaintext --------------------------------------
>>
>> <!-- AES-Key is in hex "000102030405060708090a0b0c0d0e0f"
>> <!-- 1 -->
>> <root>999.999.999 EUR </root>
>> <!-- 2 -->
>>
>> ------------------------------------------------------------
Received on Tuesday, 8 January 2002 10:08:15 GMT

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