I’m criticizing WireGuard. Or more accurately I’m criticizing NDSS for accepting a paper with no security proof. I don’t know the precise relationship between WG and Noise. If you say they’re exactly the same, then that seems twice as bad. But irrelevant to NDSS.
-
-
Replying to @matthew_d_green @tqbf and
Except there's no part that's "bad" to be twiced. Noise has real merits and is a solid set of protocols that lives up to rigorous security analysis. We're now starting to get the first batch of proofs and analysis of Noise protocols. Things are looking quite positive, not "bad"
2 replies 0 retweets 0 likes -
Replying to @EdgeSecurity @matthew_d_green and
And, you can certainly count on there being new, additional, proofs of Noise (and by extension of WireGuard). But sure, if your beef was NDSS accepting papers that didn't provide a proof (even though a proof came a bit after), okay then.
1 reply 0 retweets 0 likes -
Replying to @EdgeSecurity @tqbf and
That’s my beef, as laid out in the tweet that started this whole thing. Also I’m surprised that Trevor didn’t find a way to solve this problem early on.
2 replies 0 retweets 0 likes -
Replying to @matthew_d_green @tqbf and
That's the point you keep missing. It's *NOT* a "problem". It's a feature, not a bug, to do confirmation on the transport layer. Please read this post: https://lists.zx2c4.com/pipermail/wireguard/2018-January/002333.html … It allows us to have a DH-only protocol with only two non-droppable messages.
2 replies 0 retweets 0 likes -
Replying to @EdgeSecurity @tqbf and
First off, the “fix” doesn’t increase the number of rounds, does it? Second, surely there is an alternative fix that satisfies your requirements.
1 reply 0 retweets 0 likes -
Replying to @matthew_d_green @tqbf and
Did you read that mailing list post? I've pasted it a few times here. The modification increases the number of non-droppable messages. It's not suitable for a real world WireGuard protocol. Kenny, Ben, and I discussed this and were in agreement.
2 replies 0 retweets 0 likes -
Replying to @EdgeSecurity @tqbf and
I’m still convinced there’s an alternative tweak that wouldn’t increase the number of messages.
2 replies 0 retweets 0 likes -
Replying to @matthew_d_green @tqbf and
Without introducing signatures? Keeping it DH-only? Good luck. If you've got cryptographic advancements like this, I'm sure
@trevp__ and the Noise mailing list would be very interested to hear your suggestions.1 reply 0 retweets 0 likes -
Replying to @EdgeSecurity @tqbf and
I’m still not clear why the extra (Paterson) message flow can’t be a few extra bytes in the same message as the first normal record flow.
1 reply 0 retweets 0 likes
Because it'd have to then be in every message, due to drops. Same problem as the original. It'd also hurt the MTU and make the state machine hugely more complicated. An additional mandatory message is not acceptable.
-
-
Replying to @EdgeSecurity @tqbf and
Wait, but the first transport message is “special” already, right? It includes a timestamp that the other messages don’t include?pic.twitter.com/mAinqjyUiZ
1 reply 0 retweets 0 likes -
Replying to @matthew_d_green @EdgeSecurity and
I may be misreading this section. But if the first message is special and different from the other messages, how do you survive a drop of that message.
1 reply 0 retweets 0 likes - 6 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.