Hacker News new | past | comments | ask | show | jobs | submit login

What I am wondering is why they chose 25519.

It would seem to me that offering NTRU Prime or one of the other NIST finalists would be a prudent future protection.

https://csrc.nist.gov/Projects/Post-Quantum-Cryptography/Rou...




Doing DH with Curve25519 is a broadly understood conventional public key based key agreement scheme. We have good reason to think these are an excellent, fast, secure way to do things, unless your adversary has a working large Quantum Computer so that they can use Shor's algorithm.

NTRU Prime is for a post-quantum KEM. This does, yes, solve the same piece of the puzzle in a sense. But it's essentially one enormous experiment. Huge breakthroughs in cryptanalysis for this stuff happen all the time, by next week you might believe NTRU Prime is a joke and nobody should ever have used that, which makes requiring it at the core of a new "secure" service in Linux seem like maybe a bad idea. Bernstein and co. caution, in their submission of NTRU itself, that "the security of lattice-based cryptography is not well understood. There are serious risks of further advances".


The docs do say: "Finally, WireGuard is cryptographically opinionated. It intentionally lacks cipher and protocol agility. If holes are found in the underlying primitives, all endpoints will be required to update."

ECDH 25519 will fall like a house of cards to a capable quantum computer. Since Wireguard is already entirely DJB, the introduction of a tiny bit of agility with one of Bernstein's submissions (Classic McEliece, NTRU Prime, Post-quantum RSA-Encryption/Signature, and SPHINCS+) seems far from unreasonable.

On the other hand, I'm on Oracle Linux, so I get a new kernel about once a week anyway. Swapping out might not be that traumatic for me, since I can ksplice it into critical systems.

Android, however, cannot do that.

p.s. ...after further reading, Wireguard does have optional, pre-shared symmetric keys. This isn't an ideal solution, but it's something anyway.

"In order to mitigate any future advances in quantum computing, WireGuard also supports a mode in which any pair of peers might additionally pre-share a single 256-bit symmetric encryption key between themselves, in order to add an additional layer of symmetric encryption."


You can use WireGuard with rather expensive but conservative PQ primitives like Classic McEliece using the PSK feature of WireGuard, giving you hybrid PQ secrecy. The PSK feature was explicitly designed for this. The idea is that first you create a normal WireGuard tunnel. Then _through it_, so that it's authenticated, maybe even over boring old TCP, you negotiate your potpourri of experimental post quantum exchanges, maybe several of them if you don't want to trust a first round NIST submission right off the bat. Then you put the resultant key from this into WireGuard's PSK slot, and voila, now you have post quantum forward secrecy.

The Noise protocol framework (on which WireGuard is based) is now looking into doing PQ authentication, so that will be interesting. But until we actually have a clue which PQ primitives to use and have spent some time working out PQ handshakes, I think it's best to keep this all separate and ad-hoc, making it possible with the simple PSK feature.


Does this hold up though?

The PQ algorithms are only adding anything in scenarios where real adversaries can run quantum algorithms to break public key crypto. In those scenarios you don't have worthwhile authentication in WireGuard itself because your adversary broke that with their quantum computer.

The claim of "forward secrecy" seems particularly dubious when resorting to PSKs. Forward secrecy relies upon keys being ephemeral. The PSKs a TLS 1.3 web server remembers for minutes or hours automatically to support fast session resumption maybe count; some semi-detached manual PQ key agreement procedure sounds like it'll get done once and then left in place, no forward secrecy there.


If you believe that demanding agility is "far from unreasonable" I strongly recommend taking that line rather than insisting people should use relatively untried shiny new toys out of fear of a monster that may not actually be under their beds.

I don't know that WireGuard's author will agree, but you at least have a coherent argument that makes sense. Replacing 25519 with NTRU because you're terrified of a bogeyman (in the form of Quantum Computers able to run an algorithm that solves the appropriate hard problem) doesn't make sense.


I never said "instead of," although I can see in hindsight why it might be seen that way. I should have been more clear.

Wireguard could have used P521 and AES-GCM with similar security, but it would be slower and equally vulnerable.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: