On Sun, Dec 25, 2016 at 11:42 PM, Baptiste Jonglez <[email protected]> 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. _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
