In public key cryptography we can also use session keys which are symmetric. How do the sender (say a server) provides this session key information to its clients?

If the sender (here server) provides the session key by encrypting using its private key, all the clients (including a malicious one) can decrypt (using available public key) and see that session key , right? The server can't use public key to encrypt the session key since none of the clients have private key to decrypt it.

I am wondering what information I missed here to understand the basic idea of distribution of session key?

  • $\begingroup$ Diffie–Hellman key exchange is one possibility. $\endgroup$ Nov 29, 2011 at 10:36

2 Answers 2


Normally, the client sends the session key. This means that clients cannot decrypt other session keys.

Although this approach ensures each session is safe from information gathered in other sessions, it doesn't guard the session against an attacker later acquiring the server's key and retrospectively decoding all recorded sessions.

To guard against that threat is termed Perfect Forward Privacy. This can be achieved using ephemeral Diffie-Hellman (EDH,DHE) key exchange.

There is an excellent blog explaining recent improvements in Perfect Forward Secrecy which is well worth reading.

  • 1
    $\begingroup$ Although this is not the way it's typically done, here's a simple way to understand how it can be done: The client generates a random key pair and encrypts the public key with the server's public key, sending the result to the server. The server decrypts the client's temporary public key and encrypts a random session key with it and sends it to the client. They now have a shared secret, and so long as both sides forget all the temporary values, the key will be forever lost when the session ends. $\endgroup$ Nov 29, 2011 at 19:48

Actually, the first sentence "In public key cryptography we can also use session keys which are symmetric." is a bit misleading, if followed by the second sentence. The public key part is there just to make sure that the session key gets securely to its receiver.

In general, for a one-directed information transfer from Bob to Alice, Bob can use Alice's public key to encrypt something, and Alice will use her private key to decrypt the same information. In hybrid schemes, this something is usually a symmetric session key, which will be used for encryption (and integrity check) of the main message. If the encryption scheme is secure (and Alice's private key stays private, and Bob really has her public key), Eve (the attacker) has no chance to read (or modify) the data.

This is used for emails (e.g. PGP and S/MIME), data storage (where Bob = Alice), and other off-line communication.

For a broadcasting scheme, the session key would have to be encrypted with all the intended receivers' public keys (in parallel), so each of them can decrypt the session key using its own private key, and then use the session key to decrypt the data.

Encrypting something using the senders (private or public) key is not useful in any way.

For one-line communication, we usually want to secure not only data transfer in one direction, but bi-directional communication. At the same time, often one of both sides (often the "client") wants to stay anonymous, while at least one side has to be authenticated in some way. Here the common "public-key encryption" way is that Bob creates some random data, encrypts it by Alice's public key, and sends it to her. Alice decrypts it, and both derive some common secret keys from this random data. Alice can then encrypt data to Bob with this session key, without even knowing who Bob is.

This is the core of RSA key exchange as used in SSL, and as Will answered, as soon as someone gets Alice's private key, all the previous interactions can be decrypted.

To avoid this problem and achieve perfect forward security, one can use something like the Diffie-Hellman key exchange (or its elliptic-curve version). In this, both Alice and Bob send generate some (short-lived) private key, generate a public key from this (which is exchanged unencrypted), and combine the received public key with their own private key to get the session key – miraculously, they both will derive the same secret, and an attacker will not be able to do so. (The private keys can be destroyed after deriving the shared secret.)

To make sure that Eve is only listening and not doing an active attack, there still needs to be some way to make sure the messages are not modified (a man-in-the-middle attack). For this, usually Alice will (using her private key) sign a hash of all messages part of the exchange, and send this to Bob, so Bob can verify with her public key that he is really talking with Alice, and not to Eve pretending to be Alice. (Thus here we need an asymmetric signature scheme, too: RSA, DSA and ECDSA are popular choices here.)
(Alice doesn't really care with who she communicates, as long as it is the same entity throughout the connection, which is ensured by the MAC used for all messages. If Alice also needs Bob to be authenticated, this can be done afterwards, for example with a password, or a client certificate.)

This is also a popular mode of using SSL (as it is secure against long-term attackers), and the only mode in the SSH 2 protocol.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.