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

[whatwg] PeerConnection: encryption feedback

From: Adam Barth <w3c@adambarth.com>
Date: Thu, 17 Mar 2011 20:07:41 -0700
Message-ID: <AANLkTimzCASKt0s0C3VSK0hxddyMsLpmoFcSXsTXuczA@mail.gmail.com>
On Thu, Mar 17, 2011 at 7:51 PM, Glenn Maynard <glenn at zewt.org> wrote:
> 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.

The attacker observes each packet once delivered, so you need a new
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.

Then the MAC would fail because we're using encrypt-then-mac.

Adam
Received on Thursday, 17 March 2011 20:07:41 UTC

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