TLS 1.3 Ciphersuite SHA Level

Question

As I like to make my tin-foil hat using only the finest quality metal, I was overjoyed to see that Firefox/NSS (I'm using Arch Linux) has recently added support for the P-521 ECDH group in compatibility with TLS 1.3 (albeit not part of suite B).

It has supported ECDSA public keys using the secp521r1 named curve for a long time and AES256 (in some form) for a very long time.

For the first time in a very long time (or possibly ever) it seems to me that it is now possible to actually achieve 256 bits of effective symmetric security taking into account the weaknesses in other components of the crypto stack.

I am basing this assumption on an oft cited academic paper [did not see the need to dig it up for this question but it was put together by top men] that set out the corresponding public key length in RSA and EC terms for a given symmetric key length. This paper effectively says 2048RSA is roughly equivalent to 112bits and that EC key lengths are roughly half the strength of symmetric keys (i.e. secp256k1 == 128bits).

Now, TLS 1.3 has a maximum SHA2 level of 384bits and Firefox does not exceed the standard in this respect. The specific cipher suite am deploying is ECDH-AES256-GCM-SHA384 (w/ P-521).

My question to crypto.SE is- what am I losing in terms of encryption security by having client browsers supporting a max of SHA384?

My question has two supporting addenda/subqueries: Firstly, the checksum would seem irrelevant to me given I'm using an AEAD (AES256GCM) cipher. What am I missing here?

Secondly, in case somehow I'm missing the point and (speculating) the SHA384 somehow refers to authentication with respect to the ECDH component of the stack- is my risk here (assuming my attacker can find collisions for SHA384 but NOT for SHA512) that my attacker can inject false messages into my communications or could it (very remotely) strengthen my attacker's ability to decrypt my communications?

Finally, I'm well aware that the weakest link in my attack surface area is in so many other easier places than the cryptographic primitives, however, for the sake of good tin foil and for my OCD, it would be really lovely to get some guidance.

Finally- oh how it would be nice for every browser and every crypto library in the world to support AES, Threefish, quantum resistant algos, Ed448 (Big one that I would trade the others for), SHA3, Twofish, etc. Add all this bloat in and leave it to implementers to configure and choose wisely.

Answer 1

Firstly, the checksum would seem irrelevant to me given I'm using an AEAD (AES256GCM) cipher. What am I missing here?

Well, what you're missing is what TLS does with the specified hash. Contrary to your assumption, it does not append a hash to each record; as you point out, that'd be silly.

Instead, it uses it for two purposes:

• Within the Key Derivation Function, that is, as a part of the infrastructure that maps P521 shared secrets and public data to actual keys

• To summarize the exchange transcript (to detect downgrade attacks)

Which leads us into your next question:

is my risk here (assuming my attacker can find collisions for SHA384 but NOT for SHA512) that my attacker can inject false messages into my communications or could it (very remotely) strengthen my attacker's ability to decrypt my communications?

If the attacker is attempting to listen into a negotiation between two honest parties, he doesn't get to chose what is hashed; that means that a collision attack wouldn't apply (because a collision attack assumes the adversary has the capability to select both values that hash to the same one). And, even if the adversary were able to inject his chosen plaintext (e.g. via a Javascript applet), that wouldn't help, because what is hashed is selected by the TLS implementations and not the applications.

My question to crypto.SE is- what am I losing in terms of encryption security by having client browsers supporting a max of SHA384?

It wouldn't appear that you're missing much at all; other parts of the system would appear to be more vulnerable.