In a TLS handshake using DH to negotiate a session key, a prime number on both sides must exist. Calculating a prime number large enough to be secure takes a litte computational time.
When does chrome generate this number?
-
Are you sure both sides have their own? Don't both sides use the server's prime number?– Joseph Sible-Reinstate MonicaFeb 11, 2020 at 21:01
Add a comment
|
1 Answer
Never. Chrome does not support FFDHE (which is how TLS calls Diffie–Hellman over the multiplicative group of integers modulo p) since 2016. Chrome only support ECDHE over NISP P-256, NISP P-384 and X25519 (ECDHE over Curve25519).
When chrome used to support FFDHE, the group and generator were set by the TLS server, not the TLS client, and the group prime was generally either a value from the RFCs (Oakley group) or a value generated by running openssl dhparam 2048 (or the moral equivalent), usually once on install and never again.
In TLS DHE, the values generated online (the ephemeral keys) do not require generating large prime numbers. For more, see for example these two excellent crypto.SE answer on the properties of p and q for secure DH by Thomas Pornin.
The cryptography code in Chrome is open source, and is used also in Android and in Google's servers. It's Google's fork of openssl called BoringSSL. The main people working on it are Adam Langley and David Benjamin. You can read the code and often the explanation for why something was done. For example, DHE support was dropped because too many servers use a 2048 bit cert and 1024 bit DHE, and this is insecure, but the servers will only get fixed in practice when they upgrade the OS, which for LTS OSs can take a very long time.
If you want to read similar code that is in use, you can look at openssl 1.1.1.
TLS state machine, choosing DH group, generating key.
Inside choosing group, we see that if not overriden, you get values from RFC (not generating new group online during TLS handshake).
Inside generate_key we see the private key is just random bits. No generating large prime numbers in sight. The public key is computed from the private key by modular exponentiation.
-
1For TLS1.2 or lower since 2016 RFC 7919 recommends, and TLS1.3 (since 2018) requires, that if you use FFDHE you use the groups in RFC 7919, which are created by the same NUMS method as Oakley but with slightly different constants and don't include any choice smaller than 2048. AFAICT OpenSSL as of 1.1.1 doesn't implement these cases. Feb 12, 2020 at 8:04
-
AFAIK, nobody supports DHE with TLS 1.3. Because people worry about NSA precomputing attacks on the group, people use custom groups. That was for example reason given why nginx doesn't use 2048 bit group from an RFC and instead instructs the user to run dhparam. The group choosing logic in openssl is not great, but nobody will spend time improving it since the right solution is to use ECDHE.– Z.T.Feb 12, 2020 at 9:42