Comment by DyslexicAtheist | Hacker News Reader

Comment by DyslexicAtheist | Hacker News Reader

DyslexicAtheist

AES gets all the marketing glory. You ask the company how are they doing security? Marketing person says: "It's secure we're using AES.". AES is often the only technical word they use when they say it's secure in product brochures because they know this is going to satisfy a clueless CISO with a purchasing budget to cover their behind.

But fast forward from 2009 take a look at OTR and their decision to switch from AES to ChaCha20 (see https://github.com/otrv4/otrv4/blob/master/architecture-deci...) - the document nicely highlights why AES might not be the best choice:

> We use ChaCha20 as the encryption stream cipher because it is faster than AES in software-only implementations, it is not sensitive to timing attacks and has undergone rigorous analysis ([3], [4] and [5]). We chose this over AES as future advances in cryptanalysis might uncover security issues with it, its performance on platforms that lack dedicated hardware is slow, and many AES implementations are vulnerable to cache-collision timing attacks [[6]].

But AES is so much faster because some SSD's can offload it to hardware right? See:

256-bit AES encryption broken in SandForce SSD controllers: https://techreport.com/news/23096/256-bit-aes-encryption-bro...

Self-encrypting SSDs can easily be cracked: https://portswigger.net/daily-swig/self-encrypting-ssds-can-...

Crucial and Samsung SSDs' Encryption Is Easily Bypassed: https://www.tomshardware.com/news/crucial-samsung-ssd-encryp...

...

Also in practice it's not the crypto that gets attacked but the implementation of said crypto.

So it seems that if I have a large number of architectures and devices my software might be running on which is outside my control then the ability to predict how my crypto implementation will affect the performance of my device is a good enough reason alone to not use AES. But I might be wrong maybe others can throw in some thoughts.

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.

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.

But AES is so much faster because some SSD's can offload it to hardware right? See:

AES hardware on SSD controllers is just marketing. CPUs have had hardware AES support since 2010.

Still saves CPU cycles. We're talking about max 7GB/s for PCIe Gen4x4. Software based encryption also add small latency.

Only the higher-end CPUs like i5 and i7 in laptops. IIRC and no clue about AMD

Reply on news.ycombinator.com