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

Yes. But in the real world negotiation has consistently been a huge problem leading to lots and lots of problems.

I rather put my stack into the best currently known crypto rather then a highly complex cipher negotiation process.

In terms of negotiation there is a lot of room between the two extremes of "none" and "highly complex" but I agree that one of the big appeals of Wireguard is that you no longer have to fill out weird spec sheets to coordinate the used cipher suites with the admin on the other side of the connection.

Having said that I still would have preferred for something like a single increasing integer as the "cipher suite version". This would have allowed for the option of updating Wireguard asynchronously on both ends without any additional configuration or cipher suite coordination with the peer.

> Having said that I still would have preferred for something like a single increasing integer as the "cipher suite version".

This already essentially exists. If the first byte of an initiation message is 0x1, then it means you're using "Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s" "WireGuard v1 zx2c4 Jason@zx2c4.com". It seems like this thread is going in circles based on incorrect information about how the thing actually works.

As you have stated elsewhere negotiation has been a huge problem in other protocols and makes things much more complicated and I agree with that. My concern was merely with how absolute this stance is i.e. if the sentiment runs along the line "Wireguard will only ever support a single version and potential upgrade paths are the problem of the users" or more like "Wireguard will avoid negotiation wherever possible but when the cipher primitives are deprecated (not broken) by the community we might support introducing a replacement but keeping support for the old primitives for a while for upgrade purposes".

Have you considered mentioning the way you intend to deal with cipher breakage/deprecation more explicitly on the Wireguard page?

... but, that's exactly the root cause of previous failures. wireguard is basically saying "we don't know how to do that well enough, so we're not baking it in for now".

Why does the "increasing integer" matter to you? In what way is it better than "I am willing to protocol 1, 4 and 7" (implicitly "but not 2, 3, 5, 6, 8, 9, 10,"...)? And the "I am willing to .." is just a successful handshake. You try in order of preference; If you succeed, other side supports it. If you don't, you go to the next one. Wireguard does not produce a response unless to a non-confirming attempt.

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