Snapshot `0.0.20161223` Available

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new snapshot, 0.0.20161223, has been tagged in the git repository.

Please note that this snapshot is, like the rest of the project at this point in time, experimental, and does not consitute a real release that would be considered secure and bug-free. WireGuard is generally thought to be fairly stable, and most likely will not crash your computer (though it may). However, as this is a pre-release snapshot, it comes with no guarantees, and its security is not yet to be depended on; it is not applicable for CVEs.

With all that said, if you'd like to test this snapshot out, there are a few relevent changes.

== Changes ==

* config: allow removing multiple peers at once

Before, specifying several peers to remove on the command line at the same time would not work. This is now fixed.

* routing-table: simplify and mask reparented root

Now reparented entries in the routing table are properly masked, so that you don't wind up with strange entries like "192.0.0.0/0".

* tools: allowed-ips is easier to parse with spaces instead of ", "

This is a slight change in the tools CLI that should make it easier to parse with scripts.

* tools: do not use AI_ADDRCONFIG

It is now possible to configure IPv6 endpoints before IPv6 interfaces have successfully gotten their IPs.

* wg-config: cleanup ip parsing
* wg-config: cleanups

General cleanups.

* cookies: use xchacha20poly1305 instead of chacha20poly1305

This is a big change. To simplify the security analysis, improve speed, and simplify the code, we now use XChaChaPoly1305 with a random 24-byte nonce, instead of using a random 32-byte salt.

As always, the source is available at https://git.zx2c4.com/WireGuard/ and information about the project is available at https://www.wireguard.io/ .

This snapshot is available in tarball form here:
https://git.zx2c4.com/WireGuard/snapshot/WireGuard-0.0.20161223.tar.xz
SHA2-256: bbd98ff6667e76ac283685db9ee7a6777529f5d311a0bf1fe9a15932aed2b972
BLAKE2b-256: 19f4754d95971842f868ea95fffe7b590b40dfab7e728c7d747da822a6c73dc7

If you're a snapshot package maintainer, please bump your package version. If you're a user, the WireGuard team welcomes any and all feedback on this latest snapshot.

Thank you,
Jason Donenfeld

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAlhdhcoQHGphc29uQHp4 MmM0LmNvbQAKCRBJ/HASpd4DrpzWD/9H0tB42ZHzgf071FhFiG5lHmEIU3UYyJoZ l95ynx1utOVQXM6CUXUBUtMyAz9eiFnrWZ59k35ItmJR1WFL8YiuZ1A3sR9GJ2iY ZeS5SbdCQbxfu+K07Rz64bFkpuJ2gCt3UoHhWXQsBbLuMlQSY1arSW2ttv0gtrNS rsljpkFncNBxbbE9Jkt7SPbHWHrIveL8BzcIv5DPUd2QoHGsl1KDijneRWpZd6zW 9EhWlNGWarK35IbdWrMSQAcYbzgCgWk0ulJ8RXNQ2CjHD4h0sx12nM8NTYPTx0Hk B8WLY1BSoxZ2+atTShotBFUvRKVlLylTr9WFxCvChVCNazBVZJkefYiSonDm6h7e phwA44pJOfOZ3tE/10CHeQ0bNE2IUp+z+sXQO/gR6v6B7DaPQvq4X/my33OihGIZ /lwNjWDrl9N8MJlFF+l48B00O0P1QBJP6J8E+vQpxahQshaEaBT9ZK/weNM1Ks0N JmqRWPzukH+AiuoYhpmN1LZw/XnU+ZPMZ0Ngm9oSvNtYNX99YaG/Iq6mOceEcQsG P2VRGw9GITx1QzPxbOxYRWOz5C4B4Dj7ZbsJwM54bhr4pSEfTXQumBAE0XQQIdMI QP5Jx7EMntBKF9ZFTUbtMUxCLyjMmvDGqfTJW/yr9IVK3HYqaYpvhdI3odXgzRRt RHE5Ybfe3g==
=ULSh
-----END PGP SIGNATURE-----

I still don't understand what the change to AI_ADDRCONFIG means/does.

Are you saying fe80:: addresses are useful?

This is just on the tools. Sometimes people like to specify IP addresses in their config files for endpoints of peers:

[Peer]
PublicKey=ABCDE
Endpoint=[2607:5300:61:14f::c05f:543]:24444

And then they like to call wg setconf early on in their init scripts to parse the config file and setup the interface.

I pass all endpoints to getaddrinfo, regardless of whether or not its an IP or a hostname, since getaddrinfo is good at deciding what's what and what to do. The problem before was that getaddrinfo would refuse to parse v6 addresses if there wasn't an interface with a v6 address. Removing AI_ADDRCONFIG fixes that.

https://git.zx2c4.com/WireGuard/commit/?id=bfe364e18364cdd9a1cb6fa545a3240c93a33c83

Hi,

- Is this backwards compatible?

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

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

Thanks,
Baptiste

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

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

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