It takes two to ChaCha (Poly)
blog.cloudflare.com
It takes two to ChaCha (Poly)
1–10 of 20 posts
Re: It takes two to ChaCha (Poly)
#2AVX2 usage reduces clock frequency for a millisecond. It's suspicious (?) that performance numbers were given in terms of clock cycles and not wall clock time. It might have even worse system performance impact for small messages, where one takes the AVX2 clock frequency hit for little gain.
Re: It takes two to ChaCha (Poly)
#3AVX2 usage reduces clock frequency for a millisecond. It's suspicious (?) that performance numbers were given in terms of clock cycles and not wall clock time. It might have even worse system performance impact for small messages, where one takes the AVX2 clock frequency hit for little gain.
Cycles per byte is pretty standard for crypto algorithms, and tends to give consistent results across an architecture. It is usually measured with dynamic frequency scaling disabled.
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.
Re: It takes two to ChaCha (Poly)
#4AVX2 usage reduces clock frequency for a millisecond. It's suspicious (?) that performance numbers were given in terms of clock cycles and not wall clock time. It might have even worse system performance impact for small messages, where one takes the AVX2 clock frequency hit for little gain.
Cycles per byte is pretty standard for crypto algorithms, and tends to give consistent results across an architecture. It is usually measured with dynamic frequency scaling disabled. 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. [.…
Check out the "Intel AVX Instructions Optimization" slide on
http://anandtech.com/show/10158/the-intel-xeon-e5-v4-review/....
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.
Re: It takes two to ChaCha (Poly)
#5AVX2 usage reduces clock frequency for a millisecond. It's suspicious (?) that performance numbers were given in terms of clock cycles and not wall clock time. It might have even worse system performance impact for small messages, where one takes the AVX2 clock frequency hit for little gain.
It is true for AVX too. The entire crypto in OpenSSL uses AVX/AVX2, including RSA and AES-GCM, so for crypto heavy servers, it is unlikely to ever leave AVX mode.
Re: It takes two to ChaCha (Poly)
#6Reading about djb makes me feel really unproductive and stupid :) He wrote daemontools and solved most issues that systemd tries to solve years ago, wrote qmail and basically designed the blueprint for writing secure daemons on Unix. He wrote a secure wrapper for using C library functions safely, created a build system that is similiar to NixOS and solves most of the pains of the Unix filesystem hierarchy. Wrote a secure BIND DNS replacement and I've probably forget lot's of other archivements in cryptography and mathematics linke DNSCurve, ECC ciphers and MACs. https://cr.yp.to/djb.html
Re: It takes two to ChaCha (Poly)
#7Can you whitelist Tor on blog.cloudflare.com, at least? :-)
Re: It takes two to ChaCha (Poly)
#8Adoption of ChaCha20/Poly1305 isn't so much to have a "backup" to GCM; it's because GCM sucks.
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.
Re: It takes two to ChaCha (Poly)
#9Earlier quoted context omitted.
Cycles per byte is pretty standard for crypto algorithms, and tends to give consistent results across an architecture. It is usually measured with dynamic frequency scaling disabled. 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. [.…
Check out the "Intel AVX Instructions Optimization" slide on http://anandtech.com/show/10158/the-intel-xeon-e5-v4-review/... . 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 ru…
Interesting, that seems to contradict the information in http://www.intel.com/content/dam/www/public/us/en/documents/...
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."
Re: It takes two to ChaCha (Poly)
#10Reading about djb makes me feel really unproductive and stupid :) He wrote daemontools and solved most issues that systemd tries to solve years ago, wrote qmail and basically designed the blueprint for writing secure daemons on Unix. He wrote a secure wrapper for using C library functions safely, created a build system that is similiar to NixOS and solves most of the pains of the Unix filesystem hierarchy. Wrote a se…
Similar thoughts. :)
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/