[ANNOUNCE] Snapshot `0.0.20161223` Available

[ANNOUNCE] Snapshot `0.0.20161223` Available

[Jason A. Donenfeld]

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

Re: [ANNOUNCE] Snapshot `0.0.20161223` Available

[Dave Taht]

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

Are you saying fe80:: addresses are useful?

Re: [ANNOUNCE] Snapshot `0.0.20161223` Available

[Jason A. Donenfeld]

On Fri, Dec 23, 2016 at 9:19 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 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

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

[Baptiste Jonglez]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

Hi,

On Fri, Dec 23, 2016 at 09:15:28PM +0100, Jason A. Donenfeld wrote:
>   * 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.

- 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: 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@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.