1
$\begingroup$

The certificate used in https://de.wikipedia.org/wiki/Authenticated_Encryption has

  • public key ECC
  • public key parameter ECDSA
  • key usage digital signature

It is used to setup a secure TLS connection.

So far I know, that a so called pre-master-secret is generated by client ant sent encrypted to the server, using its certificate.

But what crypto-primitive is used for encryption in that case? The public key is used for digital signature, ECDSA, but signing something is NOT encryption.

How then is the pre master secret encrypted?

Improve this question
$\endgroup$
2
  • $\begingroup$ For your convenience: The Qualy's report for the domain in question. $\endgroup$
    – SEJPM
    Jan 26, 2017 at 10:25
  • $\begingroup$ Probably more practical people than me that can answer this better, but why do you believe the pre-master-secret is generated by encrypting and sending it? If you get elliptic curves involved, it would seem more logical to do a Diffie-Hellman (ECDH) key-exchange instead. $\endgroup$
    – CurveEnthusiast
    Jan 26, 2017 at 10:33

1 Answer 1

Reset to default
6
$\begingroup$

How then is the pre master secret encrypted?

It isn't.
What you're looking at is the ECDHE key exchange for TLS.
The short description is that the server and client run a classic Diffie-Hellman key exchange (on an elliptic curve) and use the resulting shared secret as the pre-master secret. This is unlike the RSA Key-Transport case where the client picks a pre-master secret and sends a public-key-encrypted copy to the server.

Now for the technical details (from RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2"):
The client sends its list of supported cipher suites (in ClientHello) and the server responds with the cipher suite picked, which is TLS_ECDHE_ECDSA_CHACHA20_POLY1305 in this case (happens in ServerHello). In the same run the server sends its public, ephemeral ECDH key (in ServerKeyExchange) which is most likely a point of Curve25519. The client receives this and responds with his hown public key (again a point) and the client also computes the shared point and then uses the full x-coordinate as the pre-master secret. As soon as the server receives the client's public key it also computes the pre-master secret (ie the x-coordinate of the shared point).

Now both parties share the same pre-master secret, exchanged using ECDHE.

Improve this answer
$\endgroup$
5
  • $\begingroup$ So this is regular Diffie Hellman ? This contradicts to my question crypto.stackexchange.com/questions/42353/… where I was told in the first answer, that this is not DH. I'm worried now? Does it mean DH is used when ECC is used whereas the pre-master secret is generated by the client and encryped using RSA? $\endgroup$
    – MichaelW
    Jan 26, 2017 at 11:01
  • $\begingroup$ OK, I see there are many different methods. Not just one. This explains why I was worried. Right? $\endgroup$
    – MichaelW
    Jan 26, 2017 at 11:06
  • 2
    $\begingroup$ @michael indeed, if you use RSA key-transport the client has full control over the pre-master secret, as opposed to DH where both parties negotiate the pre-master secret on the fly. And yes, TLS knows quite a few key-exchange primitives which may or may not be drastically different to each other. $\endgroup$
    – SEJPM
    Jan 26, 2017 at 11:12
  • $\begingroup$ And what is ECDSA used for in this case? I guess that the ephemeral public point generated on the server is signed and verified by the client. But the ephemeral public point of the client is sent "unprotected", because client cannot sign with severs public key. Right? $\endgroup$
    – MichaelW
    Jan 26, 2017 at 16:13
  • 1
    $\begingroup$ @michael indeed the client's point is only signed when client authentication is requested. But as long as the client properly verifies the signature of the server (and the server's certificate) this is still secure. $\endgroup$
    – SEJPM
    Jan 26, 2017 at 16:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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