RSA certificate key length vs. CA RSA certificate key length
General security question...
Does the length of the CA certificate 1024/2048 or the certificate signed by the CA determine the complexity of the SSL handshake.
i.e a 1024 cert issued and signed by a CA with a 2048 root cert. Is the SSL handshake checking only the 1024 issued cert or also the 2048 CA root cert?
Trying to dunerstand the relationship of the two certs durign SSL handshake.
Any ideas?
Comments
-
That is a really good question.
The short answer is "no". The complexity of the handshake remains the same except that for some parts, the client needs to use a 2048 bit key and at another point use a 1024 bit key.
Using a bigger key is more complex in one sense. It is certainly more work. As you may or may not know, RSA encryptions and decryptions are expensive. You want to use the smallest keys you can safely get away with. As of a few years ago, the recommendation has been that all new RSA keys have a 2048-bit public modulus, but there are still plenty of 1024 bit keys out there. My personal PGP key created in the late 1990s is a 1024 bit key.
Common RSA misunderstandings
Let me also take this opportunity to point out that the key size requirements needed for the RSA algorithm are very different than the key sizes needed for things like AES, where 128 bits is easily sufficient. This is because any 128 (or 256) bit number can be an AES key, but an RSA key has a particular mathematical structure. It can be (incorrectly, but usefully) thought of as the product of two large prime numbers.
The other thing to point out here just to get out of the way is that the RSA algorithm is not the same thing as the company "RSA Inc.", even though the latter takes its name from the former. So when you hear news about "RSA" suffering from various security problems, it is important to check out whether the news is about the algorithm or the company.
Certificate authentication
After the client and server agree on an SSL/TLS version the server
sends its certificate to the client. This it is all up to the client to
see whether it is going to trust that certificate. For this job it
doesn't actually use the RSA key of the site's certificate, instead it
uses the RSA public key of the certificate authority (CA) that signed
the site's certificate.So when your web browser gets the agilebits.com certificate during a handshake, it will not be doing anything with the agilebits.com public key. Instead it will be working with the public key of "AlphaSSL CA - G2", the intermediate CA.
Your browser will then use the public key of that intermediate CA to
decrypt the signature on the Agilebits certificate.If the decrypted
signature matches what it should be, then the browser knows that the
AgileBits certificate was, indeed, signed by the private key the CA.
The browser repeats this to check the signature on the intermediate CA,
which itself is signed by a root CA.It trusts that the root CA really
is the root CA certificates are shipped with the operating system or
browser. Note that CAs can go
bad.So this has been two RSA signature checks before the browser has has had to make any use of the public key in the AgileBits certificate.
Site authentication
If all has gone well, the client knows that it has been given a certificate that really does belong to AgileBits. But now it has to verify that the connection is indeed from AgileBits. Anyone can put a copy of our site certificate on their site. But only we know the secret key that corresponds to the public key in our certificate.
This happens as a matter of course during "key exchange". The client uses the public key in the certificate it received in the process of working out a shared secret session key (such as for AES or 3DES). So this is when the public key in the site certificate gets used.
One RSA en/de-cryption per certificate
As I mentioned above RSA encryptions and decryptions are expensive. So we want to minimize them. Here is the order in which those would take place in the above example.
Client uses the public key of the intermediate CA that signed the site certificate to decrypt the signature on the site certificate.
The signature could only have been created with the intermediate CA's private key.
Client uses the public key of the root CA that signed the intermediate CA to decrypt the signature of on the intermediate CA
Th signature could only have been created with the root CAs private key.
Client uses the public key of the site certificate to encrypt material to the server.
The key exchange process can only succeed if the server is able to decrypt that message with its private key.
If a key is broken
If someone is able to figure out the AgileBits.com private key, say by factoring the public key, they could both masquerade as us and decrypt traffic sent to us. But if someone is able to figure out the private key of a trusted CA, they can create bogus cite certificates for anything they wanted. So the security requirements on a CA's key are more stringent.
The AgileBits.com RSA key is 2048 bits long, but as I said, you will find a few 1024 bit certificates still floating around. They are taking a risk by using those, but it is far more important for CAs to use 2048 bit keys.
0 -
@jpgoldberg many thanks for taking your time to right the detailed response. I will read (then likely re-read) it and see if I really get all points made. Thanks again.
0
