It takes two to ChaCha (Poly)
blog.cloudflare.com
blog.cloudflare.com
The biggest problem for TLS with GCM is that it includes a 128 bit carryless multiplication. You can do that reasonably quickly in software, but you need lookup tables to do it, and those tables have secret indices which leave trails in caches. Modern processors have instruction extensions (like Intel CLMUL) that avoid that problem, but now you have a hardware dependency.
The big problem overall with GCM is that GCM is terrible. It fails catastrophically if random numbers get repeated, it has a short counter space, and it can blow up if you truncate MAC tags. It's weird to me that GCM has seen as much adoption as it has.
The interesting thing about ChaCha20/Poly1305 isn't the cipher (ChaCha20 is an extremely boring cipher, and while TLS won't take advantage of this, CC20 can be replaced with AES in a similar design), but the Poly1305 MAC, which was designed to be fast in software on conventional architectures.
Poly1305 as a design is pretty boring, but follows the DJB trend of taking a simple, proven idea and ruthlessly refining it for performance and safety on the kinds of computers everyone uses. Until recently, DJB was one of the only person doing that.
TL;DR: GCM is the worst.
Unfortunately, "encrypt-then-HMAC" doesn't save you from this problem; you'll either be encrypting with CBC (which loses security if IVs are predictable) or CTR (which blows up if they do). What you won't lose when that happens, though, is forgery resistance.
A good starting point for misuse-resistant authenticated encryption is SIV.
It helps that TLS-on-Intel is about the only environment in which GCM isn't too terrible (hardware support fixes side-channel attacks, short-lived connections plus key (re-)negotiation fixes the short counter space, and fortunately nobody has standardized the foot-gun that is short-MAC GCM). Also, GCM does admit very fast pipelined hardware implementations (including AES-NI).
SIV, which you suggest downstream, is indeed cool (if you can afford a two-pass algorithm). A colleague suggests that GCM-SIV is likely to lap the CAESAR candidates for inclusion into various standards including TLS, which would be... about half as horrifying, I guess?
TL;DR: GCM is bad, but it's TLS which is the worst. ;-)
Coincidentally the 4-th draft version of AES-OCB for TLS was published [0] today, and it says that:
"Historically Offset Codebook Mode has seen difficulty with implementation, deployment and standardization because of pending patents and intellectual rights claims on OCB itself. In preparation of this document all involved parties have declared they will issue IPR statements exempting use of OCB Mode in TLS from these claims."
[0] - https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/?i...
He's author of great stuff out there, but I think his works should be treated more as showing the way of doing this or that than making you stick to his particular implementations (I'm not implying they're bad, though). For instance I prefer runit over daemontools, but quite likely without daemontools there wouldn't be runit. (Actually I want to try s6 [1] soon, as it seems another step in evolution of process supervision tooling.)
But his "build system" is actually unnecessarily non-standard and clunky. I am against autohell, but carefully crafted handmade Makefiles are really nice.
[1]: http://skarnet.org/software/s6/Do you have a source for use of AVX2 automatically reducing clock frequency? I found this:
"Because Intel AVX instructions generally consume more power, frequency reductions can occur to keep the processor operating within TDP limits. [...] Performance of workloads optimized for Intel AVX instructions can be significantly greater than workloads that do not use Intel AVX instructions even when the processor is operating at a slightly lower frequency"
Which seems to indicate that it would only trigger when you're doing a fair amount of work with it, which should be giving you a total performance benefit.
Quote:
On Haswell, one AVX instruction on one core forced all cores on the same socket to slow down their clockspeed by around 2 to 4 speed bins (-200,-400 MHz) for at least 1 ms, as AVX has a higher power requirement that reduces how much a CPU can turbo. On Broadwell, only the cores that run AVX code will be reducing their clockspeed, allowing the other cores to run at higher speeds.
Specifically, the FAQ says:
"Will running a small number of Intel AVX instructions reduce frequency below the regular marked frequency?
No, frequency will be reduced below the regular marked frequency only if a real power or thermal constraint is reached, not just due to the presence of Intel AVX instructions. Some workloads that utilize Intel AVX instructions could still achieve turbo above the marked TDP frequency."
Say marked freq is 3.4 and the CPU turbos to 3.9. GP is saying an AVX2 instruction will drop it from 3.9 to 3.7 or 3.5, while you're saying it won't drop it below 3.4.