On Thu, Mar 17, 2011 at 8:06 PM, Adam Barth <w...@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
