I am the primary maintainer. :) A minimal implementation could be much shorter, but the ref implementation is not minimal and includes a lot of features that g

I am the primary maintainer. :) A minimal implementation could be much shorter, but the ref implementation is not minimal and includes a lot of features that go far beyond the scope of WireGuard. Salsa20/12 is standard and according to the docs is considered secure. I recall that DJB initially specified the cipher with 12 rounds but added 8 more for margin. There are Salsa20/12 implementations in many crypto libraries. The best public cryptanalysis on Salsa breaks 8/20 rounds with a time difficulty of 2^251. Personally I think concern over algorithm strength is usually misplaced as long as you're using an algorithm that is not known to be very weak (e.g. DES, RC4). Halfway decent cryptographic algorithms are almost never broken. Implementations and protocols are broken all the time. One thing we did to guard against protocol issues was to implement what DJB calls "boring crypto." The cryptographic encapsulation is dirt simple Salsa20+Poly1305 constructed exactly as in the NaCl secret box functions, and nothing more. We've resisted adding more advanced features to the cryptographic layer because so far they haven't really been necessary and the risk is not worth the small benefit they may have. At the time this was designed (started in 2010) Salsa20/12 was the best option to achieve high performance across a variety of devices including ARM phones and slow VMs with a clean and small code base. If it were written today it would probably use ChaCha20 (faster) or AES-GCM since almost everything worth mentioning has hardware AES now. We will likely rev the crypto at some point but would also like to upgrade the asymmetric cipher as well. Waiting to see if the Goldilocks curves (curve448) get added to the NIST standard. They are proposed but not yet approved. If they are we'd probably go to curve448+AES256-GCM with a longer IV. That being said we're not solely oriented toward crypto and generally tell our users not to rely on network crypto as their only line of defense. Network crypto is sort of analogous to hard drive encryption. It protects you from people who don't have access to anything, but won't save you once someone gets any access beyond the perimeter. We advocate the use of encryption and authentication within networks as well if you care about security. This also guards against the discovery of a bug in any layer-- if someone breaks one layer they are confronted by another layer. An RFC-style write-up has been on the to-do list forever, but the to-do list is very long.