[whatwg] PeerConnection: encryption feedback

[Adam Barth]

On Thu, Mar 17, 2011 at 6:21 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Thu, Mar 17, 2011 at 8:06 PM, Adam Barth <w3c at adambarth.com> wrote:
>> The encryption serves two purposes.  First, it provides
>> confidentiality from eavesdroppers, as you appear to be aware.
>> Second, it provides a defense against cross-protocol attacks, which is
>> why the salt and the per-message nonce are important.
>
> Do a salt and per-message nonce help in ways that a per-connection nonce
> doesn't?  The per-connection nonce would be sent out-of-band, using the
> signalling channel.
>
> That said, I don't think there's harm in appending a fixed magic value to
> the end of the key, as the spec currently does.  I'm just not sure that it
> helps anything.

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.

>> Theoretically, we could just use an initial counter value of zero for
>> each message, but, as you point out, that would require re-keying AES
>> for each message.  Rather than the scheme you propose, it's probably
>> easier to just use the nonce as the initial counter value.  The chance
>> of randomly choosing the same nonce twice is essentially zero.
>
> The issue isn't just making sure the sender doesn't reuse a counter (though
> that's also critical with CTR).  The issue is replay attacks: making sure an
> attacker can't replay a previously-sent packet later on.
>
> 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.

>> - 5. Let masked message be the result of encrypting typed raw message
>> using AES-128-CTR keyed with key. [AES128CTR]
>> + 5. Let masked message be the result of encrypting typed raw message
>> using AES-128-CTR keyed with key and using the 16 nonce bytes as the
>> initial counter value. [AES128CTR]
>
> Oh, right--AES-128-CTR needs multiple counter values to encrypt a full UDP
> packet.  That means the actual counter value in my scheme would look like
> "packet-counter-value << 16 | offset-in-packet".  The particulars of the
> AES-128-CTR algorithm should be defined--the NIST reference only defines AES
> itself, not the CTR mode.  It also needs to specify a padding method, eg.
> PKCS7 or ANSI X.923, to pad to AES's block size of 16 bytes.  (Again,
> though, these are all well-invented wheels...)

Yep.

Adam