Public and Private Keys

SSL is based on working with public/private key pairs. You can use this pair of keys for two purposes: to prove identity and to encrypt messages. In an SSL environment, it is necessary that every host has its own public/private key pair.

Imagine that Linda wants to send an encrypted e-mail to Kylie. For this to happen, Linda first needs to get Kylie's public key. Next she can encrypt the e-mail message to Kylie with this public key; for sending encrypted messages, users always need the public key of the user to which they want to send the encrypted message. Since the public key is directly related to the private key that Kylie has, only Kylie using her private key is able to decrypt the message. All this works because Kylie makes sure everyone has a copy of her public key. To make this as easy as possible, she can publish her public key on a website, put it on a Directory server, or attach it to every e-mail she sends.

Note To make it easier for others to work with a public key, I recommend putting it on a public service like a web server or an LDAP server. This increases the trustworthiness of the key, because before putting it there, the web or LDAP server (or its administrator) has verified that it really is the key of the intended user, whereas an e-mail message can easily be forged. If you should receive an e-mail from someone stating to be Kylie with a key attached to that e-mail message, it is hard to verify that the key really is sent by that user.

You can also use public/private key pairs to establish identity. An example of this is SSH key-based authentication. In such a scenario, the user who wants to authenticate makes sure a copy of his public key is stored on the server where he wants to authenticate. Next, on authentication, the user generates a random string and encrypts this string with his private key. The result of that is the digital signature. When this encrypted string arrives at the server, the server in turn tries to decrypt it with the public key of the same user, which is stored on the server. If it succeeds, that proves the user in question is really the user he says he is, and access is granted.

Was this article helpful?

0 0

Post a comment