Add a penalty/warning when a server prefers AES256 blindly

[zzq1015]

So many servers are carelessly configured to prefer AES256. Without a long enough key exchange/certificate key, that is worthless. Therefore, I suggest to give a warning to servers:

1. Preferring AES256, and
2. Having key exchange of <=3072-bit RSA/DH or <=256-bit ECDH, and
3. Having a certificate with <=3072-bit RSA or <=256-bit EC key

Some servers prefer AES_256_CBC over AES_128_GCM, cap the grade to B.

[rdebath]

I would disagree with this for several reasons: 1) The strength of ciphers is an estimate; there is especially no certainty in the relative strengths of different classes of algorithms. Even within the class there is an attack that impacts AES256 a lot more than it does AES128. 2) The required lifetimes of the keys and algorithms are different. A 1024 bit RSA authentication key appears to be still secure right now; so it's reasonable to use it for authentication. BUT there's very little headroom so there a good chance that somebody might publish an attack that will change that next year. This is still okay if you want to keep the (recorded by the attacker) encrypted session secret for many years BUT only if you use a "PFS" mode. Using say an ECDHE algorithm of 521bits and AES256 should keep the exchange and session key secret even if quantum cryptography attacks work as well as it appears that they will. 3) The NSA might know something special about the implementation of AES128 on Intel chips so it's a lot weaker (for them) than it looks... Paranoia. This is what security is about, the balance between the many factors and possible attackers is a personal guess and changes all the time. SSL Labs primarily gives an indication of the security based on known attacks. Balancing the unknown costs of your implementation against unknown attacks is not part of that so the "best practices" part only looks for things that might be broken soon.

Re: AES_256_CBC vs AES_128_GCM Both of these are currently very strong, however, if quantum cryptography works AES128 is first on the list. The difference between CBC and GCM is not on that list. This is right in the middle of my point 3.

[Razerwire]

I would suggest the opposite of what @zzq1015 zzq1015 is requesting:

The Dutch National Cyber Security Center (NCSC) released guidelines regarding crypto in a post-quantum cryptography world: https://www.ncsc.nl/binaries/content/documents/ncsc-nl/actueel/factsheets/factsheet-postkwantumcryptografie/1/Factsheet%2BPostkwantumcryptografie.pdf

The fact-sheet is in Dutch but is based on recommendations written in English which I'll get to in a moment.

They advise the use or preference of AES-256 above AES-128 bit ciphers, the gist of it being that the use of quantum-computers might seem a distant future but it's not, (encrypted traffic could be captured and stored for decryption using quantum-computers at a later time) and AES-256 is much much more resistant to decryption by quantum-computers.

This advice is based on the: "Initial recommendations of long-term secure post-quantum systems" written by "PQCRYPTO" a research project funded by the EU.

The recommendations can be found here: https://pqcrypto.eu.org/press.html https://pqcrypto.eu.org/docs/initial-recommendations.pdf

(Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1357467 )

[rdebath]

Ah, it appears that I was wrong. ECDHE is vulnerable to Shor's algorithm (as is DHE but we knew that). So if the key exchange is captured it could be broken making the choice between AES-128 and AES-256 moot from a PQ point of view. The only way to use only PQ resistant algorithms in this landscape is to use pre-shared keys.

So you better encrypt the zip file before you upload it and put the 20 diceware word password on a postit ... a big one.

On the original suggestion, a note by the combinations that the NIST would estimate to be mis-matched might be a good idea. But capping the grade -- nope.

[Razerwire]

@rdebath

There is some benefit for going to 256 bit AES. Even though EC, RSA, DH, and DSA are all vulnerable to quantum algorithms, there will be a ramp up. Smaller key sizes will fall first because quantum is an all or nothing proposition (either you have enough bits to solve the whole problem or you get no speed up from the quantum computer). Unlike classical computers where you can do the same problem on smaller versions, just slower, a quantum computer needs to be 'big enough'.

I'm not sure how many quBits you need to solve AES 128 keys, but I'm pretty sure it's smaller than the number of bits needed to solve RSA 8K, for instance, probably more than EC p256. (Gover's algorithm uses the same basic Fourier analysis as Shor's, so it likely requires the smae number of quBits for the same classical bits).

Upshot: There is some benefit in that we are practically quantum resistant for longer with AES-256 than with AES-128.

Source: https://bugzilla.mozilla.org/show_bug.cgi?id=1357467#c8

[zzq1015]

My opinion: For TLS/SSH/IPsec, keep using AES-128, unless there's a quantum-resistant asymmetric cipher coming out (such as CECPQ1 a while ago, Chrome only used AES-256 and ChaCha20 with it). For storage, using AES-256 or ChaCha20 is WAY better.

[zzq1015]

@rdebath For AES_256_CBC vs AES_128_GCM: This is an availability issue rather than security. If a site enables HTTP/2, you can't use AES_256_CBC because it will be blacklisted by major browsers (they refuse to connect). Also, at the time when large enough quantum computers come out, AES_CBC would probably be completely broken.

[rdebath]

AIUI the issue with CBC modes is that the old TLS protocols leak "correct prefix" information so it's a protocol specification error not a direct crypto algorithm problem.

Again AIUI, http/2 is a workaround for the inefficiencies of HTTP over TCP/IP and even more so over TLS where the connection setup time cannot be hidden because providing a bypass to the security checking is a really bad idea. Actually, that might be a good reason for strongly preferring the GCM modes with http/2, they have a lower CPU load.