This is more broadly referred to as the key-exchange (see RFC 4346 Appendix F.1.1). The immediate purpose of the SSL/TLS handshake is to establish a share pre-master secret between the client and the server. This cipher suite then determines how these symmetric keys are eventually shared. The server then picks the one it wants and says so in its Server Hello message. When the client initiates the connection with a Client Hello message, it sends a list of cipher suites it supports. Which cipher suite is negotiated will depend on the client and server configuration, not on the certificate installed on the server. For example TLS_RSA_WITH_AES_128_CBC_SHA will use a 128-bit key, whereas TLS_DHE_RSA_WITH_AES_256_CBC_SHA will use a 256-bit key. The list of those defined as part of TLS 1.1 is in RFC 4346 Appendix A.5. This depends on the the cipher suite that is negotiated. My question is how would the client know to generate a random 256 bit key? (Why not 128?). Just to add some details to the existing answers. The client can now trust that any information sent via the shared key comes only from the intended server. This means any middle man in the previous step can not know the new shared key. Because the key is encrypted with the server's public key, only the server (which knows the private key) can decrypt it. The client then generates the 256 bit symmetric key and encrypts it with the server's public key and sends it to the server. When the decoded response matches the challenge, the client knows that the server responded to the request (though there may be a middle man relaying it). This occurs by the client first decoding the response to a challenge which the server encrypts with it's private key, the client can then look at the public key of the server (which is signed by a known root key that the CA(in this case DigiCert) has had included with most browsers). Instead, a symmetric key (in this case of 256 bits if supported by the browser on the client) is generated and transmitted back to the server via RSA encryption and then the rest of the data is exchanged via the shared key and a symmetric algorithm. To make the equation hard to solve requires the much larger key and also, the more information that is transmitted with the asymmetric key, the more likely it is to be broken (also, the encryption/decryption is more processor intense).įor this reason, SSL only utilizes RSA for the validation and key exchange phases. This is why the key is so much larger than the symmetric counterpart (which is only 256 bits). That said, because the algorithm is based on something that is simply really hard to figure out (but is solvable), it is less secure than a symmetric algorithm based on a shared secret, which is not mathematically solvable and does not rely on the complexity of a math problem for security (more on that later). The keys are actually related to each other, but because they are related by two very large pseudo-prime numbers (prime in relation to each other) they are very hard to figure out the private key from the public. It is composed of two pieces, a public key and a private key.
It is used for validating identity (signing) and ensuring that only an intended recipient can access the information sent (encryption). To add a little more detail, the 2048 bit RSA key is something called asymmetric cryptography.
(SSL can do the key exchange with other algorithms than RSA so I have simplified description a bit in the text above, but that's the gist of the idea.) This is done because RSA is not appropriate for bulk encryption, but symmetric encryption cannot do the initial public/private business which is needed to get things started. This setup is often called "hybrid encryption". Afterwards, client and server use the 256-bit to do symmetric encryption and integrity checks, and RSA is not used any further for that connection. The server uses its private RSA key to reverse the operation, and thus obtain the 256-bit key chosen by the client. In SSL, the server key is used only to transmit a random 256-bit key ( that one does not have mathematical structure, it is just a bunch of bits) roughly speaking, the client generates a random 256-bit key, encrypts it with the server's RSA public key (the one which is in the server's certificate and is a "2048-bit key"), and sends the result to the server. The 2048-bit is about the RSA key pair: RSA keys are mathematical objects which include a big integer, and a "2048-bit key" is a key such that the big integer is larger tbut smaller than 2 2048.
0 kommentar(er)
