W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2011

[whatwg] PeerConnection: encryption feedback

From: Glenn Maynard <glenn@zewt.org>
Date: Thu, 17 Mar 2011 22:51:03 -0400
Message-ID: <AANLkTikJ37gix3DM_AXi77jo31Tsah8TWpurgh3pe1wv@mail.gmail.com>
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, 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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:31 UTC