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

Jason A. Donenfeld Jason at
Sun Dec 25 23:55:46 CET 2016

On Sun, Dec 25, 2016 at 11:42 PM, Baptiste Jonglez
<baptiste at> 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, it's got a security

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

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:

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

More information about the WireGuard mailing list