Introduction of XChaCha20Poly1305 (Was: [ANNOUNCE] Snapshot `0.0.20161223` Available)

[Jason A. Donenfeld]

On Sun, Dec 25, 2016 at 11:42 PM, Baptiste Jonglez
<baptiste at bitsofnetworks.org> wrote:
> - Is this backwards compatible?

No, but I'm 99% sure you've never hit the code path for which this is
actually used.

> - Could you provide references describing XChaCha20Poly1305 and the
>   differences with ChaCha20Poly1305?

Mentioned in the references of
https://www.wireguard.io/papers/wireguard.pdf, it's got a security
proof:
https://cr.yp.to/snuffle/xsalsa-20110204.pdf

The basic issue is that with chapoly's aead construction, you never
want to reuse the same key with the same nonce. Before, I used to do
this:

salt = random(32bytes)
derived_key = blake2s(key=real_key, salt)
chacha20poly1305(key=derived_key, nonce=0, payload)

This works fine and is secure, since blake2 is a PRF, but it's not as
optimal as it could be. The new construction is instead:

nonce = random(24bytes)
xchacha20poly1305(key=real_key, nonce=nonce, payload)

Which is a lot more similar. Under the hood, xchacha20poly1305 expands
to basically the same thing:

derived_key = hchacha20(key=key, nonce=nonce[0:16])
chacha20poly1305(key=derived_key, nonce=none[16:24], payload)

Where in this case, hchacha20 is basically:

key_material = chacha20(key=key, nonce=nonce[0:16)
return key_material[0:16] + key_material[48:64]

In other words, we trade a computation of blake2s for a single
chacha20 core function.

The advantage is not only speed and simplicity, but also the existence
of the xchacha20pol1305 aead in libraries:
https://github.com/jedisct1/libsodium/blob/master/src/libsodium/crypto_aead/xchacha20poly1305/sodium/aead_xchacha20poly1305.c

> - What part of the protocol does this change?  Is it just the initial key
>   exchange?

It's for cookie encryption, part 5.4.7 of the paper.