Hacker News Reader

Comment by tptacek | Hacker News Reader

This is good stuff.

A nit:

Users should not use AES-CBC or GCM for encryption. Secretbox should be the default mode of storing information and users should be encouraged to use KMS.

I see where this is coming and agree in spirit, but GCM is actually idiomatic Go and implemented through the crypto/aead interface, which does about as good a job as any library at being user-proof.

I too would probably prefer code that used Nacl primitives over Seal/Open, but I would probably not flag code that didn't.

View on HN

> I see where this is coming and agree in spirit, but GCM is actually idiomatic Go and implemented through the crypto/aead interface, which does about as good a job as any library at being user-proof.

Good point, and I appreciate the (updated) Kubernetes docs do a pretty good job of telling you what the implications of using aesgcm vs secretbox are.

However, I was surprised that XChaCha20-Poly1305 wasn't recommended. XChaCha appears to check all the boxes you mentioned and is nonce-misuse resistant.

It's "NMR" in the sense that the nonce is long enough to safely use random nonces, you mean? In practice, Kubernetes can use random GCM nonces safely too. Real NMR ciphers don't just have misuse-resistant ergonomics, but also better failure modes when the ergonomics fail: if you reuse a Chapoly nonce, it blows up. That doesn't happen with AEZ or SIV.

I agree that both can be used safely. And, yes to be clear, NMR here means "less likely to happen" not "better able to handle failure." Unfortunately, AES-GCM-SIV (or AEZ) aren't yet in Go's standard lib.

But, why not use XChaCha20-Poly1305 over AES-GCM in Go? Both are "implemented through the crypto/aead" and -- to my eyes -- seem equally user-proof. Why not take the bigger nonce size?

I would prefer Chapoly to GCM.

https://latacora.micro.blog/2018/04/03/cryptographic-right-a...

AES-GCM or even CBC for that matter is not vulnerable/broken. Why did they recommend Secretbox? Is there an implementation error? I am not talking about the potential of making mistakes and using platform supported constructs.

Does it make sense to make this recommendation even if the dev did not choose a vulnerable algorithm and there aren't any issues with implementation?

In the document they say that AES-CBC is vulnerable to padding oracle attacks, and AES-GCM uses random nonces and requires key rotation after so many iterations.

CBC is vulnerable to error oracles if you don't encrypt-then-MAC it properly (without the MAC it's also malleable, which is a game-over flaw). GCM is vulnerable to a bunch of its own misuse issues; it doesn't "use" random nonces, it is conceivably (through not really realistically) unsafe to use random nonces, and if you screw up nonce handling it blows up worse than CBC does.

My point is just, these things all have rough edges.

First: it's not as simple as "broken" or "not broken". GCM in Go is provided through an AEAD abstraction that is in fact pretty close to secretbox, ergonomically. In Python, Fernet provides AES-CBC with HMAC-SHA2 with similar ergonomics. So you can't just look at the constructions in isolation.

Using CBC in a Go program would be bad indeed.

Second, while you can make CBC secure, it isn't secure by default. New designs should generally avoid CBC mode in favor of a mainstream AEAD. So while I'd happily recommend Fernet to people --- it also dates back to a time when AEAD ciphers were a little less mainstream than they've become --- I would see CBC as a design smell in a newer library.

Reply on news.ycombinator.com