- From: Dan Lanz <lanz@zolera.com>
- Date: Tue, 08 Jan 2002 11:33:29 -0500
- To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
- CC: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>, xml-encryption@w3.org
Christian Geuer-Pollmann wrote: > > > Thanks for the clarifications, and I agree this is more clear. > > However, I have just a couple more questions to ensure that I > > understand this precisely. You state that "for most such > > algorithms, the attack can be partially limited in scope by > > including a nonce of algorithm dependent length." This > > statement seems to limit the utility of the nonce to just the > > protection against the IV attack described in the first > > sentence. Isn't the nonce just as useful to protect against > > a known plaintext attack? If so, a nonce would be useful to > > any symmetric algorithm (block or stream) that has feedback > > characteristics, correct? If this is true, could we state > > this explicitly along with a more general nonce length > > recommendation? > > 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.
Received on Tuesday, 8 January 2002 11:34:25 UTC