Hacker News Reader

Comment by floatboth | Hacker News Reader

> Use a well-known secure algorithm (AES256 is considered the standard).

> Never roll your own crypto.

Directly using a primitive like AES is pretty much rolling your own crypto. (Creating an actual cipher and using it is just beyond ridiculous.)

What you should use is secretbox from NaCl (libsodium or tweetnacl). Or Keyczar, I guess that's still maintained (last commit on github is 21 days ago). Or TripleSec for long term things that you're really really paranoid about.

The point is, use a library that does authenticated encryption for you.

View on HN

It's exactly rolling your own crypto. This is the second thread today on which someone has had to point this out (thanks!).

Virtually nobody writes their own ciphers. But "Don't roll your own crypto" is still important and still very common advice. Why? Because the stuff you do to actually apply "AES256" to your data is the stuff that actually causes crypto vulnerabilities.

In fact: if you do some reading on modern stream ciphers and design your own stream cipher, and then plug that cipher into libsodium, you are probably more secure than you would be if you tried to use AES256 in your own library without libsodium!

Why is using AES-256 directly considered "bad"? Is the issue key management? RNG? Padding? Or what exactly? Genuine question.

Or do you mean that re-implementing AES-256 in your own library instead of using a well-tested implementation is "bad"?

https://www.nccgroup.trust/us/about-us/newsroom-and-events/b...

The context of the long-winded conversation you linked to is user auth and session cookies. That's a VERY specific use case for AES.

I'm talking about AES in general.

But I still skimmed through it.

TL;DR

* AES CBC instead of ECB or (gasp) Triple DES

* SHA-1 instead of MD5

* Use MACs

* Be careful with padding

* ECB is not an alternative to 3DES

* If you use 3DES or any other 8-byte block cipher you import several additional security concerns you have to code around

* If you use CBC you also have to get the IV right, which tons of carefully designed crypto has failed to do

* SHA-1 is also insecure

* Neither MD5 nor SHA-1 is a MAC

* Your choice of MACs brings with it new security pitfalls

* How you apply the MAC also has pitfalls; see, for instance, all the systems that have managed to leave CBC IVs out, because they were specified as separate arguments

* Padding is a pitfall if you use CBC... or a few other modes --- guess which!

* If you use something other than CBC you get other pitfalls

* "Be careful with padding" is a vague description of like 6 different padding vulnerabilities you have to know about

* You still haven't even generated a key yet

* In the unlikely event you get all of this right, all you've managed to do is write a very basic symmetric key seal/unseal --- you're still only 40% of the way (in functional terms) to something as simple as NaCL

So, no, I would not say that was the TL;DR of that piece. I think the TL;DR of that piece is right there in the title.

* Never said AES ECB was an alternative to DES.

* I would never use 3DES.

* I am aware of that, just TLDRing. SHA-256 is my cup of tea.

* Did I say they were a MAC? I would use CBC HMAC + SHA-256 for that.

* No idea, since I'm not an expert at AES.

I feel like you're offended that I didn't like the article. It's just an opinion, don't take it personally.

I'm not offended that you didn't like the article. I'm saying you failed to summarize it. I'm pretty sure I know what the point of this particular article was. :)

OK, fair enough.

> * Never said AES ECB was an alternative to DES.

> AES CBC instead of ECB or (gasp) Triple DES

What? This entire vein of conversation is nothing but miscommunication.

These are two choices a developer should use:

  * crypto_secretbox() and crypto_secretbox_open()
    from NaCl or libsodium
  * rm -rf code/ && shutdown

Yes, a privileged few are actually capable of cobbling together a secure cryptosystem out of AES, HMAC, SHA2-family hash functions, and maybe Ed25519 and X25519 if they have a sane implementation available. The general public should just use whatever AEAD mode they're provided and not build their own disaster.

> * I would never use 3DES.

Good.

> * I am aware of that, just TLDRing. SHA-256 is my cup of tea.

SHA-384 is mine.

https://blog.skullsecurity.org/2012/everything-you-need-to-k...

Except for passwords. You don't use simple hash functions for passwords.

> * Did I say they were a MAC? I would use CBC HMAC + SHA-256 for that.

I'm assuming you meant AES-CBC + HMAC-SHA-256 here, in an encrypt-then-authenticate mode.

By "assuming" I of course meant "hoping".

> * No idea, since I'm not an expert at AES.

AES expertise isn't the issue here. Composing a secure cryptography protocol out of standard implementations is a rare skill set among software engineers.

And I thought I couldn't have gotten a worse response! Good job :)

You can get a good example of this by simply hitting this link and reviewing the first few hits:

https://github.com/search?utf8=%E2%9C%93&q=aes+encryption

I'm not going to call out any project by name, but on the first few pages, I see:

- A project which implements unauthenticated CBC mode AES

- A project that does not, in any way, document its mode or implementation beyond "using AES 256"

- A project with <10 commits, more than two years ago, yet over 50 stars

- A project that uses mcrypt

Over all, it is easier to find a project with horrible deficiencies than anything that didn't immediately look concerning. And every one of these boasts "AES 256 encryption".

I see, thank you for explaining. I'll definitely stick to the "known" libraries if I need AES.

Be a little more careful than that. Unless you're doing TLS or PGP, you essentially want to stick to NaCL/libsodium, and nothing else.

I will keep that in mind, thanks!

What is wrong with mcrypt?

It's a low-level crypto library that leaves avoidance of virtually all the exploitable crypto mistakes as an exercise for the programmer.

I started writing an answer, but this blog is more comprehensive than anything I could put together:

https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcr...

Problem #2 is something I've hit in multiple real-world codebases.

Yep. I've used NaCl for edwardian curves using djb's boxes and it's pretty much ideal as far as I'm concerned.

Edwards curves, not Edwardian. They didn't have those curves in 1905.

Curve25519 isn't an Edwards curve. Ed25519 is the equivalent Edwards curve. Curve25519 is a Montgomery curve. NaCL uses C25519 for DH, and Ed25519 for signing.

I'm just responding to the nerd snipe (and eagerly awaiting my comeuppance from 'pbsd). You're right (in advance) that the point of using NaCL is that you don't need to know any of this trivia.

Reply on news.ycombinator.com