Re: IV (some input for you)

> (Don, what did you mean by, "by including an algorithm dependent length."
> That sentence seems to be missing something.)

<ORIGINAL version="1.111">
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.
</ORIGINAL>

<SUGGESTION>
This attack can be avoided by securing the integrity of the plain text 
data, for example by signing it.
</SUGGESTION>

The "algorithm dependent length" was about the length of a prepended Nonce. 
As I demonstrated in [1], if the Nonce is a multiple of the block length 
(which included 'as long as the block length'), the complete plaintext of 
following block can be modified in a defined manner. If tou use a block 
cipher in CBC mode and really use a Nonce, the only chance is to choose the 
length=blocklength-1.

Christian

[1] http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0026.html


>
> On Monday 14 January 2002 16:44, Christian Geuer-Pollmann wrote:
>> No, it does not matter whether you use a random number or a counter, it
>> must only be unique.
>
> It's best if its random (or close to it). See the Security considerations
> of
>   The ESP DES-CBC Cipher Algorithm With Explicit IV
>   http://www.ietf.org/rfc/rfc2405.txt
> and
>   A concrete security treatment of symmetric encryption:
>   Analysis of the DES modes of operation.
>   http://www.cs.ucdavis.edu/~rogaway/papers/index.html
>
>> 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.
>
> You have claimed integrity can be obtained under CBC by encrypting the
> IV;  Don (seems to have) claimed this is possible by including an
> "algorithm  dependent length". I've noted IACBC and CBC-MAC but I would
> just prefer to  say that CBC doesn't require the IV be secret, though
> other modes might.  (Please see the new 6.3).