> The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway. OK, if you want to

> The author seems to have enough experience with IPSec that people would dismiss his first-hand experience or benchmarks as biased anyway. OK, if you want to claim bias... I own the company behind pfSense, and am sponsoring the work to put wireguard in the FreeBSD kernel (and will pay for the additional work to put this work in pfSense.) He's right, wireguard will be no faster than IPsec given equivalent encryption schemes (say, if IPsec were to use ChaCha20-Poly1305 for the bulk encryption) because the framing overheads are within a few bytes of each other. And if you're willing to compare AES-GCM to ChaCha20+Poly1305, then AES will, indeed, almost always be faster. The author makes note of the AES-NI instructions, and Wireguard's claim to be able to use the vector (AVX512) instructions, > The WireGuard whitepaper mentions due to AVX512, ChaCha20-Poly1305 will outperform AES-NI1, but that instruction set extension will only be available on large processors which again won't help with smaller and mobile hardware that will always be faster with AES-NI. However: 1) using the vector units from inside the kernel will involve a lot more overhead if anything else (say, in user land) is using the vector unit(s). Welcome to vector context switch overhead. Tons of huge registers to save and restore. 2) near future versions of AVX512 [https://eprint.iacr.org/2018/392.pdf https://eprint.iacr.org/2018/392.pdf] will support vector versions of the AES-NI (VAES) and PCLMULDQD (VPCLMULDQD) instructions. These have been timed at over 150Gbps. Yes, that's correct.