0

I read from Wiki about TSL/SSL but there is something it seems a bit confusing for me

In order to generate the session keys used for the secure connection, the client encrypts a random number (RN) with the server's public key (PbK), and sends the result to the server. Only the server should be able to decrypt it (with its private key (PvK)): this is the one fact that makes the keys hidden from third parties, since only the server and the client have access to this data. The client knows PbK and RN, and the server knows PvK and (after decryption of the client's message) RN. A third party is only able to know RN if PvK has been compromised. From the random number, both parties generate key material for encryption and decryption.

ref: http://en.wikipedia.org/wiki/SSL/TLS

It says that if the PvK is compromised then RN is also compromised, isn't that RN is the key to encrypt the message and what is the point if it is compromised? Thanks in advance!!

1
  • As I understand it: In order to compromise the RN then either the PvK or RN must already be known. As the PvK is used to decrypt it. If someone already has access to this data then the system is already compromised and the security of the data is flawed from the start. I'm not 100% on this so won;t be posting it as an answer unless its correct.
    – Joe Taylor
    Nov 15, 2010 at 12:06

3 Answers 3

2

What you describe is the key exchange that happens during the setup of an SSL connection. The goal of this exchange is for both parties to agree on a random key, this key will then be used to encrypt all the data that is exchanged.

Before we go into the actual key exchange we need to cover symmetric and asymmetric encryption.

Symmetric encryption is what the connection will use once it is set up. One key is used for both encryption and decryption. Symmetric encryption is normally faster than asymmetric.

Asymmetric encryption uses two different keys. Normally known as the public and the private key. Information encrypted with the public key can only be decrypted with the private key.

So, start of our SSL conversation, I send you my public key. It doesn't matter if someone reads this off the wire, it's public.

You now generate a random number (or string of bytes), this is going to be the symmetric key used to secure the data we exchange. You need to send this to me in some way that won't reveal it to anyone other than me.

You encrypt the random number (session key) with my public key. This means that only someone who is in possession of my private key can decrypt our session key.

All being well, only I know what my private key is. However, if my private key has been compromised (stolen) in some way, then someone else may be able to sniff the encrypted session key off the network, use my stolen private key to decrypt it and then listen in on the rest of our supposedly secure conversation.

Assuming that I have taken good care of my private key, I now decrypt the session key and we switch to using a symmetric encryption algorithm and the now agreed upon session key to secure the rest of our conversation.

0

I'm not sure I understand the question and I'm not an expert in SSL, but:

Yes, the RN is used to encrypt the message (or more accurately to generate the key material for the session which is used to encrypt messages).

If the RN is compromised then a third party may be able to read the messages for that session (but I suspect that this wasn't your question).

By "compromised" people mean that the information is known to another party that should not have access to it.

1
  • This is what confuse me because it says"A third party is only able to know RN if PvK has been compromised."
    – Terry
    Nov 15, 2010 at 12:05
0

In my understanding RN is the encrypted value with PublicKey so it is so natural for it to be "compromised" by anyone who is sniffing the network. But it is ok since RN is not understandable and can only be decrypted by the one who has the primary key.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .