[rhymenoceros]

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.

[CiPHPerCoder]

> 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.

[tedunangst]

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

[CiPHPerCoder]

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.

[simias]

~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

[tedunangst]

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

[throw0101a]

> [...] 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).