zx2c4

It's associated per-peer, so it assures a cryptographic mapping between src ip and public key.

It's like a routing table on the way out and an ACL on the way in. Maybe an easier way to think of it.

I likewise wonder from time to time whether I should replace WireGuard's allowedips.c trie with something better: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

Thank you! I'm glad somebody appreciates it. A lot of thought has gone into the installer and upgrade aspect.

Good question! I've never tried. The NT driver makes use of some of the more advanced features of the networking stack, so possibly not. But you never know. I'd love a Wg4React.

This was just for WireGuardNT, the kernel driver for the NT kernel that Windows uses.

This project -- https://git.zx2c4.com/wireguard-nt/about/ -- is used by this app -- https://git.zx2c4.com/wireguard-windows/about/ . The former is what the signing situation was about. The latter is just signed using a normal boring (but very expensive!) EV code signing certificate from one of the CAs.

As I mentioned in the mailing list post, the Microsoft paperwork shuffling matter got dealt with rather quickly, following all the attention the HN thread from the other day got. And now we're finally out with an update!

NT programming is a lot of fun, though this release was quite challenging, because of all of the toolchain updates. On the plus side, we got to remove pre-Win10 support -- https://lists.zx2c4.com/pipermail/wireguard/2026-March/00954... . But did you know that Microsoft removed support for compiling x86 drivers in their latest driver SDK? So that was interesting to work around. There was also a fun change to the Go runtime included in this release: https://github.com/golang/go/commit/341b5e2c0261cc059b157f1c...

All and all, a fun release, and I'm happy to have the Windows release train cooking again.

Microsoft got in touch. All sorted out now.

Hopefully soon, Microsoft-willing.

No. The humans just said 60 days.

Encouraged by this thread, I tweeted about it: https://x.com/EdgeSecurity/status/2041872931576299888

This is the same problem I'm currently facing with WireGuard. No warning at all, no notification. One day I sign in to publish an update, and yikes, account suspended. Currently undergoing some sort of 60 days appeals process, but who knows. That's kind of crazy: what if there were some critical RCE in WireGuard, being exploited in the wild, and I needed to update users immediately? (That's just hypothetical; don't freak out!) In that case, Microsoft would have my hands entirely tied.

If anybody within Microsoft is able to do something, please contact me -- jason at zx2c4 dot com.

Voila:

https://github.com/WireGuard/wireguard-android/pull/82 https://github.com/WireGuard/wireguard-android/pull/80

In that first one, the double pasted AI retort in the last comment is pretty wild. In both of these, look at the actual "files changed" tab for the wtf.

On Linux, there's no need to use this. Modern Linux kernels implement getrandom() in the vDSO, which does similar buffering, and keeps those buffers safe in the event of forks or VM forks and kernel reseed events.

The readme says:

> Maintains all cryptographic security guarantees of crypto/rand

I'm not sure that's correct. If you're running this in a VM that forks, this new package will give out the same random bytes to both VMs, which could be catastrophic. If you're using normal crypto/rand, Linux has got you covered, and the VM forks get reseeded.

I was curious upon seeing this and found the thread where its inclusion was turned down: https://sourceforge.net/p/sevenzip/discussion/45797/thread/a...

> about 4x to 10x faster than channels.

I'd be interested to learn why/how and what the underlying structural differences are that make this possible.

Similar project of mine from a long while ago: https://git.zx2c4.com/cscript/about/

Linus merged it on July 24, 2024, so about a year I guess. Kernel is released ~8 weeks after the merge window, so I suppose September or so.

I think neither are unbelievably slow. I dunno, take some measurements and see, maybe it suits you.

If you don't need "predictable randomness", like for repeatable statistical simulations, then absolutely, you should only use getrandom(). On recent Linux, this is implemented in the vDSO and is super fast. Few excuses now to use anything different.

Careful with the "chacha csprng" when the seed from the seed() function appears to be 32 or 64 bits. That's not enough for the cs part. (Also the output stream appears to wrap after 2**32 blocks. Could make this larger.)

Should be fixed now. App Store needed an EU declaration.

> By the end of the training, they learned to name an average of 7.08 pitches (ranging from 3 to 12) at an accuracy of 90% or above and within a response-time (RT) window of 1,305–2,028 ms.

That doesn't actually seem very promising, or at least useful at all. It still seems way less useful than my accurate and near instantaneous relative-pitch. What could I do as a musician with 2 seconds of latency to be wrong some amount of the time.