- From: Glenn Maynard <glenn@zewt.org>
- Date: Thu, 17 Mar 2011 22:51:03 -0400
On Thu, Mar 17, 2011 at 9:28 PM, Adam Barth <w3c at adambarth.com> wrote: > So, the salt and the nonce play different roles. The salt is to make > sure the message appears random if you haven't read the spec (and so > don't know the salt). The nonce is to prevent the attacker from > crafting plaintexts that encrypt to a chosen ciphertext, even when the > attacker sees both sides of the connection. Picking a new nonce for > each message means that the attack cannot choose the bytes sent on the > wire. The nonce can be communicated in-band, just like the IV for CBC > mode. > But you get this with a per-connection (not per-packet) nonce and CTR's sequence number. You don't need a unique 16-byte nonce for each packet. > By using an increasing counter, the anti-replay algorithm from DTLS and > > IPsec ESP can be used. It's very straightforward; see > > http://www.ietf.org/rfc/rfc4347 section 4.1.2.5, which explains it > better > > than I can. This requires an increasing sequence number--this algorithm > > won't work if the counter is a random value. > > Sure. That's fine. If you like, we can XOR a monotonically > increasing value with the nonce to provide the initial counter value. > Do you mean including both a random 16-byte nonce *and* a (say) 6-byte sequence number in each packet? That would make the replay-prevention algorithm work, but creates a hole: an attacker could modify the nonce to match arbitrary sequence numbers. For example, if the nonce is 5 and the sequence number is 10, an attacker could repeat the packet's contents by creating a new sequence number (say, 500), and then fabricating a nonce N where 500^N = 5^10, resulting in the same counter value. -- Glenn Maynard
Received on Thursday, 17 March 2011 19:51:03 UTC