Reading 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…
It takes two to ChaCha (Poly)
11–20 of 20 posts
Re: It takes two to ChaCha (Poly)
#12Adoption 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…
Poly1305 also fails if nonces are repeated. If you want reuse resistance, I'd rather go for something boring like encrypt-then-HMAC than a polynomial based MAC.
Re: It takes two to ChaCha (Poly)
#13Adoption 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…
Poly1305 also fails if nonces are repeated. If you want reuse resistance, I'd rather go for something boring like encrypt-then-HMAC than a polynomial based MAC.
It does (really: everything that wasn't designed with misuse resistance as a primary goal does) --- I was imprecise. Sorry.
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.
Re: It takes two to ChaCha (Poly)
#14Adoption 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…
Among my employer's customers and employees, the people who ask for GCM really want "a TLS algorithm that isn't terrible" - and GCM is more or less the only widely-supported solution. (As you know, OCB's license made it a non-starter, CCM was slower and not Intel-supported, and most other stuff is newer than GCM.) Since people will take their cues from - at best - experts talking about TLS, even an old-fashioned solution like "HMAC plus CBC, but in the correct order" isn't on their radar.
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. ;-)
Re: It takes two to ChaCha (Poly)
#15Adoption 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…
Among my employer's customers and employees, the people who ask for GCM really want "a TLS algorithm that isn't terrible" - and GCM is more or less the only widely-supported solution. (As you know, OCB's license made it a non-starter, CCM was slower and not Intel-supported, and most other stuff is newer than GCM.) Since people will take their cues from - at best - experts talking about TLS, even an old-fashioned solu…
I think I agree with you more than I agree with me. :)
Re: It takes two to ChaCha (Poly)
#16Earlier quoted context omitted.
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 i…
No, you're actually agreeing: GP says "it reduces how much a CPU can turbo", while you are pointing out "it will not reduce frequency below the regular marked 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.
Re: It takes two to ChaCha (Poly)
#17Adoption 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…
Among my employer's customers and employees, the people who ask for GCM really want "a TLS algorithm that isn't terrible" - and GCM is more or less the only widely-supported solution. (As you know, OCB's license made it a non-starter, CCM was slower and not Intel-supported, and most other stuff is newer than GCM.) Since people will take their cues from - at best - experts talking about TLS, even an old-fashioned solu…
> OCB's license made it a non-starter
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...
Re: It takes two to ChaCha (Poly)
#18Adoption 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…
GCM is terrible, but it's not patent-encumbered, unlike OCB mode (which is otherwise superior IMHO).
Re: It takes two to ChaCha (Poly)
#19Adoption 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…
GCM is terrible, but it's not patent-encumbered, unlike OCB mode (which is otherwise superior IMHO).
OCB breaks down if nonces repeat, too (though not quite as badly). But Salsa/Poly is strictly superior to GCM.
Re: It takes two to ChaCha (Poly)
#20Reading 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 evolut…
You mean like the DJB Way? There's a website for that. http://thedjbway.b0llix.net/