He's been using pfsense for awhile now. Watching him build it and set it up was painfulLinus finally going to use pfsense
I put it to start playing 5secs before he mentions it and that works for me.24:20 in case you don't want to watch the whole video
Not as painful as watching him build / cable his server room.He's been using pfsense for awhile now. Watching him build it and set it up was painful
Well welcome. There is a ton of knowledge here and a pretty great community.I admit I'm here because of Linus (although the actual main reason I am here is because I like networking, system administration, home labbing, home servers, all that good stuff). He can definitely have his cringe moments but he's honestly pretty entertaining in my opinion.
There was a spike today. The front page Xeon discount article got picked up on [H], Reddit, Twitter and etc. Friday afternoon is usually slow for us as the EU is in the evening and the east coast US has signed off for the weekend. We have been running at about 2x normal Friday traffic most of the day.Also it would be interesting to see if there is a traffic spike or new member spike in the couple days after the video.
Intel QAT will accelerate time consuming cryptographic operations, compare@Patrick do you know what he is referring to when it talks about quickassist helping with pfsense?
on pfsense?Intel QAT will accelerate time consuming cryptographic operations
depends on the VPN implementation. for single stream openvpn, yes.Aren't VPN speeds dependent on clock speed and not core count?
And the chachapoly implementation only hits that speed with AVX-512, which isn't in most CPUs on the market. (Only the high-end server CPUs; if you have a desktop on one end you'll get a heck of a lot of AES acceleration but your chachapoly performance will be relatively worse. You're looking at somewhere around 4-5GB/s AES-128-GCM vs somewhere around 1.5GB/s CHACHA20-POLY1305.) See ARM Takes Wing: Qualcomm vs. Intel CPU comparison for a better per-generation breakdown. And if you follow the advice in the that post and abandon AVX-512 for this purpose due to the bad effects on overall performance, you're back well under 2GB/s even on the latest high-end hardware. Given the games intel's playing with AVX-512 as a product differentiator (and its lack of implementation on AMD) I don't expect that to change in the near future. Longer term maybe it'll be more available, but then we'll need to throw the new AVX AES instructions into the mix as well... (Kaby Lake has AES-GCM down to .64 cycles/byte vs , while the Ice Lake vector AES is projected to hit .16 cycles/byte; for comparison the ivy bridge architecture used on the wireguard performance page does AES-GCM in something like 2.5 cycles/byte!)Yes AES-GCM is faster. Not by much though, see It takes two to ChaCha (Poly) On older CPUs at 1.5k packet sizes with 256-bit security level AES-GCM is only ahead 30%. On newer CPUs AES-GCM is faster more like 50%, compare On the dangers of Intel's frequency scaling but on such chips ChaCha20-Poly1305 will do 2.89 GB/sec/core i.e. saturate a 10 Gbps link duplex with a single core. Impressive really, and good enough...
So, basically, there's a wholly imaginary attack against all AES-NI implementations, but no possible imaginary attack against AVX? In either case you could drop to a non-accelerated algorithm at the cost of an enormous performance penalty. It's worth noting that the AES-NI instructions were one of the few parts of the intel instruction set actually designed with side-channel resistance as a goal. (Unlike most of the recent side channel attacks, which involve functionality not explicitly designated as resistant to such attacks because nobody really cared to spend the money on that threat--including the AVX instructions.)Ever since Meltdown I am suspicious though of Intel not having yet another security problem in their silicon. Like a key-dependant timing side channel that lets you probe a system for a day and then you have the secret key of the victim server in hand. I realize this is highly paranoid thinking, but some data deserve only the best for protection. On AES-GCM you'd need to wait at least many months for Intel to come up with a microcode fix, if one is possible and this is not a FDIV kind of bug that requires a CPU swap. Which in essence would be a full system swap, because fixed CPU means different chipset means upgrade of the server. $$$ Or implement expensive flushes like against L1TF that throw you back into Haswell performance territory.
Chacha20-poly1305 could be fixed in software fast and cheap, should a problem show up. And there would be enough agility to even work around hardware weaknesses, should any more come up. After all it uses only SIMD.