1
$\begingroup$

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.

$\endgroup$
5
  • 1
    $\begingroup$ I wouldn't get too excited, P-521 is still a curve with NSA chosen (and unexplained) equation coefficients. $\endgroup$ – Woodstock Mar 20 at 10:49
  • $\begingroup$ One post should ask one question only. Please post each question separately. I suggest to close this post. $\endgroup$ – mentallurg Mar 20 at 12:42
  • $\begingroup$ @mentallurg, I did not know how to ask my main question without specifying supporting sub-qustions. In other words the sub queries provide essential context to help in the answering of my main question. $\endgroup$ – hut_rudder Mar 20 at 16:26
  • $\begingroup$ @Woodstock - I am well aware of the suspicicions surrounding the NSA curves; firstly, these are suspicions rather than there being conclusive evidence and secondly if am assuming that if the NSA wants my information, they will get it no matter what I do. They go up against adversaries with billions to spend on cyber and crypto security. I do go onto say later in my post that i would love to able to use ed448. $\endgroup$ – hut_rudder Mar 20 at 16:28
  • $\begingroup$ Note Suite B has been gone over 5 years now, although its 'temporary' replacement CNSA equally doesn't include P-521. Several of the papers or standards on keysizes are conveniently linked at keylength.com . Also in TLS1.3 keyexchange is not part of the ciphersuite; you are doing a handshake aka negotation with kx=ECDH, some authentication you didn't mention, and cs=TLS_AES_256_GCM_SHA384. $\endgroup$ – dave_thompson_085 Mar 20 at 23:46
1
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ That pretty much answers my question. If the security of the system is not prejudiced by using sha348 in ecdsa-ecdh-aes256gcm-sha384 then why does the trailing hash in the cipher suite (used, as you say for key derivation from ECDSA shared secrets into session keys plus downgrade protection), what is the purpose of using sha384 at all? Surely SHA256 would be cheaper? $\endgroup$ – hut_rudder Mar 21 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.