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

Re: nonce length

From: Dan Lanz <lanz@zolera.com>
Date: Tue, 08 Jan 2002 11:33:29 -0500
Message-ID: <3C3B1F59.795293D4@zolera.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:06 UTC