
2019 Guide to Cryptographic Key Sizes and Algorithm Recommendations - CiPHPerCoder
https://paragonie.com/blog/2019/03/definitive-2019-guide-cryptographic-key-sizes-and-algorithm-recommendations
======
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...](https://latacora.micro.blog/2018/04/03/cryptographic-right-
answers.html) 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...](https://latacora.micro.blog/2018/04/03/cryptographic-right-
> answers.html) 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.

~~~
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](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.

------
tptacek
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?

~~~
CiPHPerCoder
> 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).

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

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

------
jorangreef
"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-...](https://blog.cloudflare.com/padding-oracles-and-the-decline-of-
cbc-mode-ciphersuites/)

~~~
CiPHPerCoder
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](https://moxie.org/blog/the-cryptographic-doom-principle)

[2] [https://github.com/defuse/php-
encryption/blob/b87737b2eec06b...](https://github.com/defuse/php-
encryption/blob/b87737b2eec06b13f025cabea847338fa203d1b4/Crypto.php#L116-L122)

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

~~~
CiPHPerCoder
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).

------
throw0101a
See also:

* [https://www.keylength.com](https://www.keylength.com)

------
amanzi
Good guide, but I'd also recommend you look at your respective country's
guidance - most governments around the world will provide recommendations.

