RE: https://furry.engineer/@soatok/116088925054375056
I'm going to be very clear about something:
If you tell me that something I reported has "no security impact", I publish it as soon as possible.
If you're wrong in your assessment of the actual security impact, that's not my problem.
If you're citing an argument about the wrong level of abstraction, I will tell you you're wrong (and why) while I'm publishing.
Do you know a neat trick for avoiding this outcome?
It's called the Socratic method in fancy circles, but it's basically: Ask clarifying questions.
I want to include this excerpt from the Matrix response:
Your PoC correctly demonstrates that the Olm 3DH implementation in vodozemac does not currently perform the all-zero DH output check. As we're sure you're aware, the check for contributory behaviour in X25519 is a contentious topic among cryptographers, with some calling for it, but others like RFC 7748[1] calling it optional or even arguing against it (e.g. Trevor Perrin[2]). We've previously considered adding it but ultimately avoided it due to the conclusion that there's no practical security impact on Matrix. In other places like SAS/ECIES we explicitly reject non-contributory outputs because those handshakes can be used in unauthenticated contexts where an all-zero DH output could directly collapse channel security.
The [2] points to https://moderncrypto.org/mail-archive/curves/2017/000896.html
Which is talking about the Diffie-Hellman primitive, not what protocols building atop ECDH should do.