69

On DigiCert's page, they advertise a 2048 bit SSL with a 256 bit encryption: http://www.digicert.com/256-bit-ssl-certificates.htm

What exactly is the difference here and why are two encryption bits being referenced?

Here's a screenshot of the ad:

On Geotrust's Premium SSL ad, they advertise it as:

Security: domain control validation, strong 256-bit encryption, 2048-bit root

So what's the difference between 256 bit encryption and 2048 bit root?

Hope that clarifies the question.

muru
  • 374
  • 1
  • 3
  • 15
JohnJ
  • 857
  • 1
  • 8
  • 8
  • possible duplicate of [What does "key with length of x bits" mean?](http://security.stackexchange.com/questions/8912/what-does-key-with-length-of-x-bits-mean) – Gilles 'SO- stop being evil' Aug 30 '12 at 14:52
  • 1
    @Gilles: thanks for that link, but that's far too microscopic of an answer. I'm looking for an overview of what the difference is. – JohnJ Aug 30 '12 at 14:59
  • 7
    Hmm I don't get why a certificate vendor talks about 256 bit encryption. The symmetric encryption used by SSL is completely independent from the certificate. – CodesInChaos Aug 30 '12 at 16:10
  • @CodesInChaos: I agree, but maybe it is useful? Given the accepted answer below, my question is how would the client know to generate a random 256 bit key? (Why not 128?). If the server plays a role in the client's decision, then I can understand why the vendor would display this info. – JohnJ Aug 30 '12 at 16:34
  • 1
    @Gilles I think that question is asking more about the bit encoding of keys, whereas I believe this one is about the difference between the types of keys. – AviD Aug 30 '12 at 21:32
  • @Gilles, This question is from a "domain manager/user" POV. – Pacerier Apr 12 '16 at 10:13

4 Answers4

76

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 than 22047 but smaller than 22048.

The 256-bit is about SSL. 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 server uses its private RSA key to reverse the operation, and thus obtain the 256-bit key chosen by the client. 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.

See this answer for some more details. This setup is often called "hybrid encryption". 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.

(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.)

Community
  • 1
Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 1
    Thank you! Can you clarify this part: "the client generates a random 256-bit key"? In this case, the client is the browser? If so, does the ad mean to say that the root encryption is for the handshake portion and the 256 bit is for the data encryption? Hope I'm getting this. – JohnJ Aug 30 '12 at 15:56
  • 1
    Ignore that question - I get it now. I combined your answer with the one in this post: http://security.stackexchange.com/questions/13688/my-understanding-of-how-https-works-gmail-for-example?lq=1 Thank you! – JohnJ Aug 30 '12 at 16:22
16

To add a little more detail, the 2048 bit RSA key is something called asymmetric cryptography. It is used for validating identity (signing) and ensuring that only an intended recipient can access the information sent (encryption). It is composed of two pieces, a public key and a private key. 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.

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). This is why the key is so much larger than the symmetric counterpart (which is only 256 bits). 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).

For this reason, SSL only utilizes RSA for the validation and key exchange phases. 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.

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). 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). The client then generates the 256 bit symmetric key and encrypts it with the server's public key and sends it to the server. Because the key is encrypted with the server's public key, only the server (which knows the private key) can decrypt it. This means any middle man in the previous step can not know the new shared key. The client can now trust that any information sent via the shared key comes only from the intended server.

AJ Henderson
  • 41,896
  • 5
  • 63
  • 110
  • Great info! However, wouldn't the tougher algorithm imply a greater level of security? I'm referring this part in your answer, "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 (more on that later). " – JohnJ Aug 30 '12 at 17:42
  • @JohnJ - The problem is that it is solvable. A symmetric algorithm (based on a shared secret key) does not publicly provide the information necessary to solve it. There are some tricks that can be used to make more educated guesses, but it does not rely on a problem being hard to solve. If anyone ever came up with a way to factor very large primes quickly however (for example, through quantum computing), RSA would immediately be broken and useless because the information shares is mathematically enough to determine the plaintext. – AJ Henderson Aug 30 '12 at 18:09
  • 3
    To clarify further, RSA is the asymmetric, 2048bit algorithm, while the symmetric is the 256 bit portion. Most of the attacks against symmetric encryption involve looking for either a known plaintext (the thing being encrypted) or patterns that result due to poor key selection or a problem in the underlying algorithm, but that is all based on analysis of the cyphertext as opposed to analysis of the key itself (since the key is unavailable). The inherent weakness in asymmetric cryptography is that the public key must be related to the private key and thus the private key can be derived. – AJ Henderson Aug 30 '12 at 18:18
  • 1
    Thus the security of the asymmetric algorithm is dependent entirely on how hard it is to solve for the private key given the public one. – AJ Henderson Aug 30 '12 at 18:20
  • There is no "challenge" "encrypted with private key" (which is not an accurate description of signing anyway; there are dozens of questions about that). For DHE and ECDHE key exchanges as described by Bruno, but not pure-RSA you and Thomas describe, the server *adds* a signature to the ServerKeyExchange message, whose contents are neither chosen nor echoed by the client, and which is *after* the server cert (really chain) is sent and (presumably) validated. For pure-RSA the only server proof of possesion is the correctly MACed Finished message. – dave_thompson_085 Mar 14 '15 at 06:15
9

Just to add some details to the existing answers...

my question is how would the client know to generate a random 256 bit key? (Why not 128?).

This depends on the the cipher suite that is negotiated. The list of those defined as part of TLS 1.1 is in RFC 4346 Appendix A.5. 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.

Which cipher suite is negotiated will depend on the client and server configuration, not on the certificate installed on the server. When the client initiates the connection with a Client Hello message, it sends a list of cipher suites it supports. The server then picks the one it wants and says so in its Server Hello message.

This cipher suite then determines how these symmetric keys are eventually shared. The immediate purpose of the SSL/TLS handshake is to establish a share pre-master secret between the client and the server. This is more broadly referred to as the key-exchange (see RFC 4346 Appendix F.1.1).

This falls in two categories (excluding anonymous key exchange):

  • RSA key exchange (e.g. TLS_RSA_WITH_AES_128_CBC_SHA): the client encrypts the pre-master secret using the server's public key (found in the certificate).
  • DH(E) key exchange (e.g. TLS_DHE_RSA_WITH_AES_256_CBC_SHA): a Diffie-Hellman key exchange takes place. The server signs its DH parameters and the client verifies the signature against the public key in the server certificate. (Having an RSA-based certificate doesn't imply an RSA key exchange.)

At the end of the handshake, whichever of these two steps were used, the client and the server are in possession of a common pre-master secret, from which they derive a master secret (see RFC 4346 Section 8.1).

From that master secret, both parties can derive the encryption keys (and MAC secrets), as described in RFC 4346 Section 6.3.

Besides the key type (RSA or DSS), there is nothing in this that makes the size of the encryption key depend on the certificate. In addition, both types have cipher suites that use 256-bit keys: for example TLS_DHE_DSS_WITH_AES_256_CBC_SHA and TLS_DHE_RSA_WITH_AES_256_CBC_SHA. (DSS is a signature-only algorithm, so you wouldn't get an RSA-like key exchange to encrypt the pre-master secret.)

The size of the key in the certificate only matters to prevent forgery of the key exchange (or to be able to decipher recorded traffic back): if someone was able to find the private key from the public key in the certificate, they could act as a MITM to impersonate the real server or they would be able to decipher the enciphered pre-master secret (and thus the recorded traffic) when using an RSA key exchange (DHE cipher suites are precisely designed to prevent getting access to the pre-master secret, even if the attacker gets hold of the private key and the recorded traffic, see this question). This is why a sufficient large asymmetric key matters.

Certification Authorities tend to put "256 bits" on their websites because it looks good from a marketing point of view.

It's not wrong, but it can be misleading for people who don't understand that it's how your server is set up and what your clients support that matters.

Community
  • 1
Bruno
  • 10,875
  • 1
  • 39
  • 61
  • 1
    In addition to integer DH, there are also suites using *Elliptic Curve* DH (ECDHE_*); these have security properties essentially the same as DHE, in particular PFS, but use much smaller keys, usually double the size of symmetric encryption for comparable security; see rfc 4492. Also rfc 4346 for TLSv1.1 is superseded (or at least supplemented) by 5246 for TLSv1.2, which alters details of the PRF used in 6.3 and 8.1 but not the basic idea. Lastly, CA and cert is irrelevant to symmetric strength now, but not always, see http://stackoverflow.com/a/29045932/2868801 . – dave_thompson_085 Mar 14 '15 at 06:08
0

From Digicert: https://www.digicert.com/ssl-cryptography.htm

"Public Key Infrastructure (PKI) uses a hybrid cryptosystem and benefits from using both types of" "(Asymmetric and Symmetric) encryption."

"Asymmetric encryption (or public-key cryptography) uses a separate key for encryption and decryption."

"Symmetric encryption (or pre-shared key encryption) uses a single key to both encrypt and decrypt data."

"Public-key cryptography (asymmetric) uses encryption algorithms like RSA to create the public and private keys." "RSA is based on the presumed difficulty of factoring large integers." "keys smaller than 2048 bits are no longer considered safe to use"; "would take an average computer more than 14 billion years to crack."

"Symmetric key sizes are typically 128 or 256 bits." "a 128-bit key has 340,282,366,920,938,463,463,374,607,431,768,211,456 encryption code possibilities"; "would take quite a bit of time to break a 128-bit key."

Summary:
The 2048-bit refers to the Asymmetric encryption offered by Digicert to transfer the 256-bit Symmetric key to facilitate the data exchange (secure communication) between the client & server (via SSL/TLS).

Zimba
  • 181
  • 5
  • The same information is already provided in existing answers. Can you explain what your answer offers that others don't? –  Sep 16 '20 at 09:57
  • @MechMK1: I just summarized the answer provided at source of question (Digicert) in one sentence. Answers given here discuss verbose technicalities of algorithms, not relevance of the key size difference asked in the question. The last answer didn't explain why "256 bits" looks better than 2048-bit, even "from a marketing point of view". There's also no discussion of ECC or DSA effects from the different bit sizes. – Zimba Sep 17 '20 at 17:17