I don't understand the comment about CBC_SHA256 having no Lucky13 countermeasures. Is that an implementation choice in Go, or is there something I'm missing about countermeasures not being possible with SHA256?
Conversation
Implementation choice, AFAIK. IIRC agl wrote that cipher suites are not pokemon, you don't need them all, CBC are needed for compatibility with older non-AEAD software, use the older CBC-SHA1 for that. CBC-SHA2 are kinda pointless since HMAC-SHA1 is not broken.
1
The comment doesn't make that clear, and the links given as references don't explain it either. Also, if there's a choice not to implement a necessary countermeasure for a given ciphersuite, shouldn't it be ripped out of the code? Why leave the hazard lying around?
3
I think because it's not a very practical attack and some people need the compatibility to talk to some legacy services. Software that connects to modern things can use PFS+AEAD only. Changing the default for which cipher suites are allowed is probably a major change.
1
In situations where modern AEAD ciphers are available, none of this is relevant. My point here is that the comment as written is confusing and possibly misleading, and should come with stronger "we left a known hazard in here by choice and you should know about it" language.
1
Also while I'm complaining, not everything that has AES hardware has Galois-field multiplication instructions. It sure would be nice to see the TLS 1.3 CCM suites supported in more places.
1
ChaCha12 has a higher security margin than AES256 and would be the best fit for most of those devices. It's as fast as hardware AES on most server hardware too.
There might as well be a mandatory cipher suite based on it. Once you have ChaCha20 and Poly1305 you've done the work.
1
1
Even low-end, 32-bit Android devices don't have hardware AES. GCM isn't the only issue. en.wikipedia.org/wiki/Adiantum_ is how disk encryption is provided on those now.
Smaller embedded devices have the same problem. It's even less likely those get hardware AES any time soon.
1
ChaCha12 isn’t in a standard cipher suite yet, and I’ve certainly got a bunch of smaller embedded devices I’m working with that have AES but nothing else...
(I’ll avoid invoking CAVP in this conversation but that’s certainly another common blocker to ChaCha suites)
1
also if disk encryption is enough of a performance problem that it’s necessary to engage in cryptographic novelty to solve it, maybe Google could get together with the phone OEMs and push towards hardware offload? please?
1
Snapdragon devices have it offloaded and don't need to waste cycles on the ARMv8 CPU instructions. They get the data decrypted on the way from the SSD.
Very low-end phones don't have anything. They're still ARMv7 without useful crypto accel. Also, eMMC storage, not proper SSDs.
I don't think Google has much of a partnership with the SoC vendors, etc. making those chips. Those vendors would have preferred not having encryption by default. Maybe they'll address it after having it forced on them with Adiantum. I somewhat doubt it though.