On Fri, Oct 16, 2020 at 04:19:53PM +0000, coderman wrote:
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, October 15, 2020 11:04 PM, <jamesd@echeque.com> wrote: ...
StrongSwan uses NSA approved standards. Wireguard uses no NSA standards, relying instead entirely on standards approved by Jon Callas as unelected president for life of symmetric cryptography and Daniel Bernstein as God King of asymmetric cryptography.
So, do you oppose us using Wireguard to avoid exposing ips associated with the physical address where the state can find people to beat up?
Wireguard uses entropy instructions like RDRAND directly, with no mixing. Even BSD and Linux know this is a bad idea.
https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-d...
""" As it turns out, WireGuard relies on RDRAND (when available) to generate new session IDs. The session IDs need to be unique, and WireGuard wants them not to be simple consecutive integers, so it pulls a pseudorandom value from RDRAND, compares it against its existing session ID list to make sure there's no collision, then assigns it to the session.
Read that last part again carefully—it makes sure there's no collision first. If an existing session has the same ID as the new number, WireGuard asks RDRAND for another "random" number, checks it for uniqueness, and so on. Since RDRAND on my system—and any non-microcode-updated Ryzen 3000 system—always returned 0xFFFFFFFF no matter what, that means infinite loop. Infinite loops in kernel code are bad; they introduce you to the value of the hardware reset button in a hurry. """
at least wireguard is fast? :P
HA! That is fire trucking hysterical muh grits. Thanks coderman, important to know. Anyone know if Debian/ Fedora/ Ubuntu patch this underminer away? Not that I've used wireguard yet..