Big numbers make my head hurt

May 14, 2008 11:19 AM

Can someone help me understand the relationship between the bit size of an SSL certificate and the size of the session key used? (If any).

Essentially, my question is this: Does generating a 512 bit certificate signing request limit the session key in any way? Or rather, is a 512 bit CSR capable of facilitating a reliable 128 bit session key?

I am usually pretty good at googling stuff like this, but I am striking out this time. Some of the pages I found indicate that the only thing that determines the session key is the capabilities of the web server and web client. Other pages indicate that a 512 bit CSR limits you to a 40/56 bit session key. Is there any hard rule on this?

For the purposes of this question, assume I have to use a 512 bit certificate. Also assume, I know about the mounting risks with 512 bit keys and that I know a 1024 bit key is much more secure.

(While I am on the subject, how does Verisign's mandatory 128 bit session encryption work? Is that a matter of signing the cert with only certain encryption protocols allowed?

I just heard about this for the first time the other day. Apparently, there is a standard signing process where the session key size fluctuates based on the connecting browser and there is an 'enhanced' cert that makes 128 bit mandatory. How is this any different than selecting 'require 128bit encryption' in IIS?)

posted by cayla to technology (3 comments total)

I'm a little rusty, but I'll give it a shot.

You have a private key and a signed public key. You generated the private key on your server with 512 bit encryption and used a CSR to have a public key signed against it. The private key is basically a code that has been signed by a Certification Authority (CA) to indicate that you can be trusted. The encryption level of your private key simply makes it harder for that private key to be cracked and misused.

When an https session is enabled, the browser authenticates your signed key against a trusted root through the signed certificate (and possibly intermediate certificates). If it can verify that your key is trusted, all of the data is then encrypted by the browser on the way to the host. This encryption is done by the browser and has nothing to do with the encryption level of your key itself.

Think of the two things separately. You can have a private key built on 512, 1024, 2048, even 4096 bit encryption, and still have a browser session that is only using 256 bit encryption, because that's all your browser/server can handle.

No idea about verisign's certs, you may want to ask them.

In general, the session is encrypted with the highest level possible by the browser/connecting device and the server itself. Some browsers/devices/servers aren't capable of 256 bit encryption, so the number goes down until you get a mesh that works.
posted by phredgreen at 1:24 PM on May 14

I'll jump in as well and say first off I don't know if there is a relationship between the Public Key Size of the cert and the size of the session key used. However I will say that a big part of what SSL (and now more precisely TLS) does is protocol negotiation. The browser and server does an exchange of all the protocols they know about and the strongest one that they have in common is the one that is used. An example list of these cipher protocols can be seen in Apache's SSL documentation. There are clearly weaker and stronger certs available. Part of this is just the natural evolution of the SSL scheme and part of it based on United States and other governments having strict limits on the types of cryptography that could be exported. Lastly as the Wikipedia article suggests, some of the protocols are deprecated in later versions of SSL and TLS because of flaws in the protocols themselves.

Lastly, at least for Apache, the types of protocols that are allowed is completely configurable by the admin as indicated by the SSLRequiredCiphers directive that you can add to the config file. I don't know much about IIS and SSL but there probably is a way to achieve something similiar.
posted by mmascolino at 3:05 PM on May 14

Thank you both.

I do grok that the public key is distinct from the session key and that there is a difference in key lengths between symmetrical and asymmetrical . I think I just misunderstood something I read on the subject that made me think there was some shared property between the two. Like, maybe there was some determination along the line of if the public key was small enough to be cracked before the session key, the extra session key length was wasted. Doesn't the public key seed or provide the transfer of the session key? Does this make any sense?

I don't know why I missed this before but I just found this link: http://en.wikipedia.org/wiki/Server_gated_cryptography. I am pretty sure this is what Verisign is hawking. So, if I am understanding mmascolino's explanation right, the enhanced cert is just another check to make sure that the best cipher is being used. That makes sense.

So, while the verisign enchanced cert it a good measure, it really isn't doing anything you can't do in the web server config.

Thank you again.
posted by cayla at 5:33 PM on May 14