2

The question comes from the accepted answer in this thread: My understanding of how HTTPS works (gmail for example)

    1. The Gmail server sends your client a certificate. The certificate includes the Gmail server's public key, and some evidence that this public key actually belongs to gmail.com.

    2. Your browser verifies the evidence in the certificate, to confirm that it has the proper public key for gmail.com.

    3. Your browser chooses a random new symmetric key K to use for its connection to Gmail. It encrypts K under Gmail's public key.

    4. Gmail decrypts K using its private key. Now both your browser and the Gmail server know K, but no one else does.

    5. Anytime your browser wants to send something to Gmail, it encrypts it under K; the Gmail server decrypts it upon receipt. Anytime the Gmail server wants to send something to your browser, it encrypts it under K.*

Regarding this step, "your browser chooses a random new symmetric key K", what is the number of bits in this key that the browser generates?

From another thread I posted (see: Understanding 2048 bit SSL and 256 bit encryption), I get the impression that it's a 256 bit key.

How can I verify this?

Community
  • 1
JohnJ
  • 857
  • 1
  • 8
  • 8

2 Answers2

4

As per the SSL/TLS standard, the gory details are the following: if the cipher suite which the client and server agree upon mandates RSA-based key exchange, the the client generates a 48-byte (384 bits) string, beginning with the protocol version over 2 bytes, then 46 random bytes (i.e. 368 random bits). This is the PreMasterSecret (see section 7.4.7.1). This is the string which is encrypted with the server's public key.

When both the server and the client have the 48-byte pre-master secret, they use the PRF (the kind-of hash function described in section 5) to deterministically compute, from the pre-master secret, the encryption and integrity keys used to protect the data. If the cipher suite calls for 256-bit encryption keys, and 256-bit encryption keys will be thus generated.

To see from within the web browser (assuming the SSL client is a Web browser), see this answer.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • excellent info! Thanks for the link to the other post as that answers another question I had. – JohnJ Aug 30 '12 at 17:53
2

That's going to depend on what the server and browser support and allow. My understanding is that there is a handshake process by which the server and browser agree on the symmetric algorithm and key length to be used for exchange. 128 bit is fairly standard, though 256 is supported and many servers support lesser bit levels for countries that are on export exclusion lists for 128+ bit encryption algorithms.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110