* [ANNOUNCE] Snapshot `0.0.20161223` Available
@ 2016-12-23 20:15 Jason A. Donenfeld
2016-12-23 20:19 ` Dave Taht
2016-12-25 22:42 ` Introduction of XChaCha20Poly1305 (Was: [ANNOUNCE] Snapshot `0.0.20161223` Available) Baptiste Jonglez
0 siblings, 2 replies; 5+ messages in thread
From: Jason A. Donenfeld @ 2016-12-23 20:15 UTC (permalink / raw)
To: WireGuard mailing list
-----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-----
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ANNOUNCE] Snapshot `0.0.20161223` Available
2016-12-23 20:15 [ANNOUNCE] Snapshot `0.0.20161223` Available Jason A. Donenfeld
@ 2016-12-23 20:19 ` Dave Taht
2016-12-23 20:22 ` Jason A. Donenfeld
2016-12-25 22:42 ` Introduction of XChaCha20Poly1305 (Was: [ANNOUNCE] Snapshot `0.0.20161223` Available) Baptiste Jonglez
1 sibling, 1 reply; 5+ messages in thread
From: Dave Taht @ 2016-12-23 20:19 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
I still don't understand what the change to AI_ADDRCONFIG means/does.
Are you saying fe80:: addresses are useful?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [ANNOUNCE] Snapshot `0.0.20161223` Available
2016-12-23 20:19 ` Dave Taht
@ 2016-12-23 20:22 ` Jason A. Donenfeld
0 siblings, 0 replies; 5+ messages in thread
From: Jason A. Donenfeld @ 2016-12-23 20:22 UTC (permalink / raw)
To: Dave Taht; +Cc: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Introduction of XChaCha20Poly1305 (Was: [ANNOUNCE] Snapshot `0.0.20161223` Available)
2016-12-23 20:15 [ANNOUNCE] Snapshot `0.0.20161223` Available Jason A. Donenfeld
2016-12-23 20:19 ` Dave Taht
@ 2016-12-25 22:42 ` Baptiste Jonglez
2016-12-25 22:55 ` Jason A. Donenfeld
1 sibling, 1 reply; 5+ messages in thread
From: Baptiste Jonglez @ 2016-12-25 22:42 UTC (permalink / raw)
To: wireguard
[-- 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 --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Introduction of XChaCha20Poly1305 (Was: [ANNOUNCE] Snapshot `0.0.20161223` Available)
2016-12-25 22:42 ` Introduction of XChaCha20Poly1305 (Was: [ANNOUNCE] Snapshot `0.0.20161223` Available) Baptiste Jonglez
@ 2016-12-25 22:55 ` Jason A. Donenfeld
0 siblings, 0 replies; 5+ messages in thread
From: Jason A. Donenfeld @ 2016-12-25 22:55 UTC (permalink / raw)
To: Baptiste Jonglez; +Cc: WireGuard mailing list
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-12-25 22:48 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-23 20:15 [ANNOUNCE] Snapshot `0.0.20161223` Available Jason A. Donenfeld
2016-12-23 20:19 ` Dave Taht
2016-12-23 20:22 ` Jason A. Donenfeld
2016-12-25 22:42 ` Introduction of XChaCha20Poly1305 (Was: [ANNOUNCE] Snapshot `0.0.20161223` Available) Baptiste Jonglez
2016-12-25 22:55 ` Jason A. Donenfeld
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).