4 ms·

Only if you're using the ridiculous IPsec protocol and its ridiculous modes. Nobody actually needs a mode that authenticates the header but doesn't encrypt it,

Only if you're using the ridiculous IPsec protocol and its ridiculous modes. Nobody actually needs a mode that authenticates the header but doesn't encrypt it, and nobody can understand this mode anyways. Nobody needs ECB or 3DES or any of the other zillions of IPsec methods. The great thing about WireGuard is that it removes all the crap and has one mode: Fast and Secure.

tialaramex 8y ago
The slightly dated TLS 1.3 talk from Rescorla talks about this briefly, this is not a situation with easy answers and the approach taken in WG, which is also the approach in TLS 1.3, may yet turn out to be a bad idea. In TLS 1.3 they have left themselves a fire exit they can run out of, hair ablaze, but it's not clear to me whether WG has a way out. From an API point of view, "Fast and secure" sounds pretty good. It maybe infantalizes the Software Engineer, which we're not really ready for yet‡, but we get more ready all the time, so I'll let that go. It's certainly better than "No real security unless you're an expert" which was historically what such APIs tend to offer. On the implementation side "fast and secure" is just a wish, not a fact. Individual elements, picked for being "fast and secure" may turn out not to be as fast as we'd like on tomorrow's hardware, or they may not turn to be as "secure" as we'd have liked. IPsec's Chinese Menu approach lets the software engineer pick something else, but WG's approach doesn't permit this. So, the entire protocol must perhaps be re-designed. ‡ Twenty years ago, we had no good "This just works" answers for a great many things software engineers expect from cryptography. Today we have good answers for many of them, e.g. AEAD modes for block ciphers do roughly what a non-expert software engineer foolishly thought the encryption did anyway. But for others we're still in the dark. Padding for example. For privacy we should pad lengths to hide the true nature of the data being transferred. But... how much should we pad? Today our answer is that hopefully the software engineer using the API knows. In almost all cases they do not.

tialaramex 8y ago

The slightly dated TLS 1.3 talk from Rescorla talks about this briefly, this is not a situation with easy answers and the approach taken in WG, which is also the approach in TLS 1.3, may yet turn out to be a bad idea. In TLS 1.3 they have left themselves a fire exit they can run out of, hair ablaze, but it's not clear to me whether WG has a way out. From an API point of view, "Fast and secure" sounds pretty good. It maybe infantalizes the Software Engineer, which we're not really ready for yet‡, but we get more ready all the time, so I'll let that go. It's certainly better than "No real security unless you're an expert" which was historically what such APIs tend to offer. On the implementation side "fast and secure" is just a wish, not a fact. Individual elements, picked for being "fast and secure" may turn out not to be as fast as we'd like on tomorrow's hardware, or they may not turn to be as "secure" as we'd have liked. IPsec's Chinese Menu approach lets the software engineer pick something else, but WG's approach doesn't permit this. So, the entire protocol must perhaps be re-designed. ‡ Twenty years ago, we had no good "This just works" answers for a great many things software engineers expect from cryptography. Today we have good answers for many of them, e.g. AEAD modes for block ciphers do roughly what a non-expert software engineer foolishly thought the encryption did anyway. But for others we're still in the dark. Padding for example. For privacy we should pad lengths to hide the true nature of the data being transferred. But... how much should we pad? Today our answer is that hopefully the software engineer using the API knows. In almost all cases they do not.