3 ms·
The reference has been lost in the mists of time, but before snowden, and the NIST backdoors, there were accusations that a member of the SSL standardizations c
by hedora 3y ago
The reference has been lost in the mists of time, but before snowden, and the NIST backdoors, there were accusations that a member of the SSL standardizations committee was an NSA plant that intentionally sabotaged the protocol.
Since their actions were done in public, researchers went back, and found that their main contribution to the spec was blocking anything that would simplify the implementation, and fast tracking as much needless complexity as possible.
From what I can tell, Wire Guard is based on that story, since it doesn't include any session-time negotiation of ciphers, etc.
tl;dr: Runtime negotiation of encryption algorithms considered harmful.
- jvanderbot 3y ago> From what I can tell, Wire Guard is based on that story, since it doesn't include any session-time negotiation of ciphers, etc. Wireguard exchanges keys prior using well trusted implementations, and common "wireguard-implemented-tools" facilitate key generation and exchange on top of that. This is sane, and only vulnerable to supply-chain attacks in libsodium, or key leaks at either: a) compromised host (so that host can decrypt incoming traffic) or b) the key-exchange mechanism, for which open source implementations exist e.g., Nebula / Tailscale. Regardless ... Given that it is in addition to ssh (it's ssh over wireguard, not ssh or wireguard), I find any arguments against a wide class of encryption standards to be not very compelling. With ssh + wireguard you need state-level hacks on libsodium and ssh vulnerabilities to have a general-purpose attack like you see with the Snowden stuff However, this is important context.