Hacker News Reader

Comment by api | Hacker News Reader

There's a lot of FUD and misunderstanding here.

Phrases like "we are secured with AES" are just marking babble by people who don't understand the details.

AES is significantly faster in hardware if there is support. The vast majority of non-embedded chips (and some embedded) now have AES support in the CPU core including virtually all x64 and aarch64 chips sold today. AES is slower than ChaCha without hardware support but constant time "bit slicing" implementations exist that are fast enough for most use cases.

The broken crypto you cite was due to bad implementations or improper use. AES was not broken. You're definitely right that the implementation almost always is what gets attacked, but that's as true with ChaCha as it is with AES. Any crypto can be used incorrectly and any software can have bugs.

Nothing wrong with ChaCha, but don't spread FUD.

View on HN

Included in the box when you buy an AES are several different cipher modes, many of them are most useful for injecting slugs of metal into you own feet.

The one you should use, AES-GCM, wasn't even in the original box, but was MacGyvered later.

I'm not convinced that people who aren't able to learn enough to use AES properly will fare that much better with ChaCha20, Poly1305, and asymmetric key agreement. ChaCha doesn't make the key agreement stuff easier and if they're going to blow their feet off it's probably going to be there.

GCM wasn't "MacGyvered" any more than ChaChaPoly. ChaCha doesn't give you authentication by itself, and you need authentication. You could in theory do ChaCha/GMAC or AES-CTR/Poly1305 and be okay if you engineered it properly. I think NaCl already has AES-CTR/Poly1305 in it.

What does asymmetric key agreement have to do with using ChaCha?

There are definitely ways in which GCM is more brittle than ChaCha; in particular, you can use random nonces with XChaCha, and you technically can't safely do that with GCM. But really, throw a dart, your outcome will be the same either way.

You mean this?

https://crypto.stackexchange.com/questions/42982/safety-of-r...

I personally prefer the SIV modes, but using a sequential nonce within a session is pretty much always better due to birthday attack stuff.

Cryptography does advance over time. When GCM was introduced it was when everyone realized that you must always have authentication and they wanted a faster auth mode than HMAC.

Makes me wonder what new understandings might be coming down the road other than the obvious quantum computing factor. The most recent one I remember is the risk of combining compression with crypto if the attacker can influence anything in the compressed data.

> AES is significantly faster in hardware if there is support.

this means relying on something that you might not be able to influence: borked HW implementations. you are essentially saying rolling out to unknown broken devices is fine because the majority of users where HW isn't broken can benefit from better performance. that's a hell of a trolley problem and precisely why OTR switched to ChaCha/Poly.

I'm not talking about one being better than the other but implementation matters and those projects (like OTR) where security is the only value proposition, then maybe AES is a risky choice?

Sure AES is maybe the victim of it's own success and if chips get ChaCha implementations in HW then we'd also have broken implementations at scale. But that wasn't my point.

Broken AES hardware would be extremely obvious via tests against known test vectors. Intentionally backdoored hardware is possible but that's a concern no matter what you are running. If your hardware is hostile you are screwed.

Reply on news.ycombinator.com