0

Forgive my inexperience with encryption, I've been researching this for the better part of the morning and still cannot find a smoking gun answer.

A vendor is requesting that we verify a website we utilize is secured using a specific cipher:

ECDHE_RSA_WITH_AES_256_GCM_SHA384

On checking the site I see it is encrypted using the following:

ECDHE_RSA with P-384 and AES_256_GCM

Would the cipher on this website satisfy their requirements? Are P-384 and SHA384 interchangeable?

Any assistance or guidance would be greatly appreciated. Thank you very much.

4
  • What do you check the site with? TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is likely the IANA name (iana.org/assignments/tls-parameters/tls-parameters.xhtml) of the cipher suite that you want. You just need a tool that lists cipher suites supported by the server. And even then, the server likely supports more than one suite, and the one actually negociated depends both one the client and the server... As for P-384 and SHA-384 they are different things, one is a NIST standardized ECC curve, the other is the 384 bits long instantiation of SHA-2. May 13, 2022 at 16:39
  • To be honest.. I checked the security tab on Google Chrome's developer tools while on the website.
    – wr mem
    May 13, 2022 at 16:44
  • If you want to check the ciphersuite, use something that actually shows the ciphersuite, not Chrome/ium. Also, it's easy to show the server can use a given ciphersuite, but essentially impossible to tell if it does or will use that ciphersuite for all connections, and extremely difficult to tell if it does or will use it for your app's connections -- exactly which are you supposed to 'verify'? May 15, 2022 at 2:35
  • SHA384 is a hashing algorithm in the SHA-2 family. P-384 is the elliptic curve (formally called secp384r1) used in ECDHE for key agreement.
    – forest
    May 16, 2022 at 1:32

1 Answer 1

1

These are two different ciphersuites.

  • With regard to ECDHE_RSA_WITH_AES_256_GCM_SHA384 - the SHA384 component is the hashing algorithm used to ensure data integrity during the TLS handshake

  • With regard to ECDHE_RSA with P-384 and AES_256_GCM - the P-384 is used for key encipherment, where the public key in the server's certificate is used to encrypt another key used during the session.

As pointed out in the comment by @BrunoRohée, the ciphersuite is negotiated between the client and the server. The server likely supports many ciphersuites. So, the ciphersuite that is ultimately used for the session may be largely dependent on the browser used and this browser's settings. In other words, you may find that a different ciphersuite is used with the same site, if you connect to the site with a different browser, or change the settings in the same browser that you used before.

2
  • The second set is not a ciphersuite at all; Chrome displays only the primitives it considers important, which does not include the hash when not used for HMAC, but does include the ECDHE curve which is not part of the ciphersuite. May 15, 2022 at 2:55
  • P-384 is used for key agreement, not encipherment. In its typical (non-static) implementation, it's not like RSA where the public key encrypts and the private key decrypts. Rather, both parties generate a keypair and exchange public keys. The remote public key and local private key are then used to generate a shared secret. It just so happens that Alice's public + Bob's private and Bob's public + Alice's private both result in the same value.
    – forest
    May 16, 2022 at 1:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .