2019 Guide to Cryptographic Key Sizes and Algorithm Recommendations | Hacker News Reader

2019 Guide to Cryptographic Key Sizes and Algorithm Recommendations

paragonie.com

126 pointsCiPHPerCoder19 comments

This post has some claims on AES that seem out of date. For instance, most CPUs nowadays support 256-bit AES without resorting to bitslicing. And most implementations have had plenty of time to address the side-channel timing attacks from djb's paper.

The recommendation for 2048-bit RSA is also a headscratcher. I get why you'd want to prefer ECC, but if you have to use RSA for some reason is there any scenario where you wouldn't also want 4096-bit keys?

Mozilla's TLS and SSH recommendations are pretty solid though.

https://latacora.micro.blog/2018/04/03/cryptographic-right-a... is an alternate, arguably better, source of information.

> For instance, most CPUs nowadays support 256-bit AES without resorting to bitslicing.

If you have the advantage of only working with newer hardware, this is true. But it's not immediately obvious whether or not your CPU supports 256-bit AES-NI without e.g. benchmarking OpenSSL.

The point isn't "AES-256 almost never supports AES-NI" (although that used to be true). It's that naively saying "biggest rock is best rock" doesn't always hold true.

> If you have to use RSA for some reason is there any scenario where you wouldn't also want 4096-bit keys?

You're sacrificing performance for a hypothetical security gain that probably won't matter. If 2048-bit RSA gets implicated by some new attack, it's more likely that 256-bit ECC will save you than 4096-bit RSA.

> https://latacora.micro.blog/2018/04/03/cryptographic-right-a... is an alternate, arguably better, source of information.

When people are asking for a guide on Cryptographic Right Answers, I always point people to that page.

The questions I wanted to address are about key size. And the point I wanted to stress was, "There are usually other factors that are far more important to consider than just the size of the key."

If I see a system that uses RSA to encrypt, I care more about it not using textbook RSA or poorly-implemented PKCS#1v1.5 padding than I do about 2048-bit vs 4096-bit keys.

Can you expand on the CPUs that support 128 bit AES but not 256 bit? I didn't know that was a possibility.

Hmm, no, I can't.

This was something I had observed in practice over the years (i.e. several orders of magnitude performance difference between AES-128 and AES-256 from my PHP implementations), and "your CPU only supports AES-NI for 128-bit keys" was the explanation I was given at the time. I haven't observed this recently, and I'm on newer hardware, so the explanation made sense.

In attempting to identify which CPUs were affected by this limitation, I've discovered that I was grossly misinformed about this. I'm going to update the article to redact this, ASAP.

UPDATE: Redaction applied.

~10 years ago I had a small fanless computer running with an AMD Geode LX CPU that supported AES-128 but not 256 in hardware.

https://en.wikipedia.org/wiki/Geode_(processor)#Geode_LX

IIRC the geode accelerator is more like a PCI device in the same SoC and not technically a CPU extension.

> [...] is there any scenario where you wouldn't also want 4096-bit keys?

For the time being, 3072b seems to be "good enough" if you want more than 2048b. It's all you need for official Top Secret stuff (per IAD-NSA), as well as BSI and ECRYPT-CSA recommendation for the next few years:

* https://www.keylength.com

There's nothing "wrong" with it per se, it's just that it's probably not strictly necessary. Why take the (potential?) performance hit by going to 4096 if it doesn't really get you anything practical?

Most people don't seem to care about whether they're using 128- or 256-bit AES, but when it gets to RSA there seems to be a bigger debate between 2048 or 4096 (with 3072 hardly being mentioned).

The problem I have with this kind of thing is that if you can get away with the idiosyncratic recommendations (XChaCha, GCM-SIV), you're not interoperating, and so you can almost by definition just use libsodium box and secret-box. Who is a laddered recommendation of different signing algorithms really helping?

> The problem I have with this kind of thing is that if you can get away with the idiosyncratic recommendations (XChaCha, GCM-SIV), you're not interoperating, and so you can almost by definition just use libsodium box and secret-box.

I absolutely am in favor of just using libsodium box/secretbox instead of having to understand this sort of nuance.

> Who is a laddered recommendation of different signing algorithms really helping?

People who ask me nitpicky questions about whether or not they should opt for 3072-bit RSA keys instead of 2048-bit RSA keys. The main purpose of the post was the first half (the "it doesn't matter" point).

I guess I sympathize. You've been doing this long enough, you should have the confidence at this point to tell the picky 3072-bit RSA people "stop designing systems, this will all end in tears". That's what we tell people! They seem to like it!

Doesn't it concern you that the NSA appears to no longer be recommending elliptic curve asymmetric crypto systems?

What the NSA appears to recommend or not doesn't cause me any significant concern.

This could happen if they're relaxing their recommendations to double down on post-quantum cryptography.

This could happen if they had a mathematical breakthrough that invalidated all ECDLP security estimates.

I'll never know which it is. The pragmatic thing is to research PQCrypto and make sure the next generation of asymmetric primitives are as good as they can be.

Their main argument is don’t spend the effort to switch to ECC since we’re going to recommend switching to a quantum resistant suite any day now.

"AES-CBC (regardless of key size) + HMAC-SHA2 (Encrypt then MAC)"

CBC is not an option that you should be considering in 2019.

https://blog.cloudflare.com/padding-oracles-and-the-decline-...

AES-CBC-HMAC-SHA2-ETM is fine as a last resort, assuming you have a secure compare function and a CSPRNG so your IVs never repeat for a given key and are unpredictable.

TLS's AES-CBC is MTE not ETM, and that distinction matters [1]. You shouldn't use CBC mode in SSL/TLS. (You also shouldn't be supporting SSL; only TLS.)

But an application-layer AE construction [2] as described in the article is fine.

[1] https://moxie.org/blog/the-cryptographic-doom-principle

[2] https://github.com/defuse/php-encryption/blob/b87737b2eec06b...

It seems to contradict itself on whether one should use 128 or 256 bit keys with AES

There's no contradiction.

It doesn't really matter which you use under most threat models.

AES-128 gets you guaranteed AES-NI on virtually all processors sold in the past decade. AES-256 gets you better assurance against quantum attackers, should they ever become a real threat.

You can side-step both of these by just using a ChaPoly ciphersuite which is constant-time and fast on all platforms, without hardware acceleration. (If you ecide to just use libsodium's box/secretbox, as Thomas said in another comment, you're doing this side-step... which is thematically appropriate for a cipher named after a Latin dance).