Re: nonce length

>> We should clarify what a Stream cipher is ;-)) If a stream cipher is a
>> PRNG (without feedback of the ciphertext into the engine but simply XOR
>> between plaintext and key stream), a Nonce is useless (like you already
>> said).
>>
>> The IV itself is used to protect the CBC mode against
>> known-plaintext-attacks. We don't need the Nonce for that.
>
> Agreed.  Is it worth exploring the utility of a nonce to
> a feedback stream cipher?  Of course, the table of algorithms
> in the specification lists no stream ciphers at all, so this may
> be a moot point anyway.  If so, dropping the nonce concept
> altogether, as you suggested, might be best.

Hm, what I would like is that Nonce to be deleted from the spec, but let's 
play the game:

Blockcipher in OFB has no feedback, so this can't be our toy. But Cipher 
Feedback (CFB) would do the job. CFB also needs an IV to bring the 
underlying block algorithm into a defined starting state. But what happens 
if I feed a random sequence of defined length into the stream chipher (with 
feedback)? I only change the internal state of the cipher, so it would be 
the same to directly start in this (seeded) state with content encryption.

I did not thought much about that but my first impression is that using a 
Nonce with a stream cipher is waste of storage and time.

Additionally, if we use a stream cipher for decrypting a multimedia stream, 
it's probably encrypted by an application that does not know anything about 
the concept of a Nonce.

Christian