- From: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
- Date: Tue, 08 Jan 2002 18:01:57 +0100
- To: Dan Lanz <lanz@zolera.com>
- Cc: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, xml-encryption@w3.org
>> 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
Received on Tuesday, 8 January 2002 11:58:44 UTC