[whatwg] PeerConnection: encryption feedback

[Glenn Maynard]

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.

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.


> - 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...)

-- 
Glenn Maynard