# How can A pass a message to B, while preventing a third party from sniffing infos?

$A$ has a message that he wants to send to $B$, without a third party being able to learn the contents of the original message.

$A$ encrypts the message and sends it to a server. The server decrypts the message somehow, and sends it to $B$. This way, no one would know what was the original sender, because the server will send it to the destination.

But if the server encrypts the message again, how will $B$ be able to decrypt the message? If $B$ knows how to decrypt the message, then any third side would also know.

What is the solution?

-
I think you are looking for a mix net with a single proxy. – DrLecter Jan 3 '14 at 9:56
Can't we establish secret keys between A,server and Server,B? – deltaaruna Jan 3 '14 at 11:13
It sounds like you mean 'origin of the' rather than 'original' in your first sentence? – figlesquidge Jan 3 '14 at 11:27
This sounds like the requirements for Tor – Maarten Bodewes Jan 3 '14 at 12:00
The question is not clear. At first, a third party should only not be able to learn the content. And then all of a sudden the third party should not be able to know who sent the message. On the "how will B be able to decrypt something", usually public key crypto will do the trick. – tylo Jan 8 '14 at 14:32

1. Server distribute respective private keys to A (PrivateKeyA) and B (PrivateKeyB) and stores their public keys (PublicKeyA and PublicKeyB) within it's database.

2. Now any of the user (eg A) generates a random session key (K) and encrypts this key with its own private key (PrivateKeyA). Since server has public key of A, it can decrypt the encrypted session key.

3. Now it encrypts the same session key (K) which it got from A with B's public key and sends it to B. Now since only B knows the corresponding private key, only B can decrypt the encrypted session key to deduce the key K.

4. Now A and B share a session key, which they can use to safely communicate with each other.

For exchanging session key the the algorithm uses asymmetric cryptography and for communication it uses symmetric cryptography technique. The only thing to keep in mind is that either user must be capable of generating a good and strong random session key.

-
Welcome to Crypto.SE. In my opinion, your answer needs more details, including the threat model you're trying to solve within. For example, how can the server send private keys to the users - any eavesdropper could just listen in to this communication. Also, AES is a symmetric cipher, but your answer sounds like you want to use it as an asymmetric cipher. – figlesquidge Jan 3 '14 at 12:53
I notice you corrected the final paragraph, but it's still unclear how you envisage the server distributing private keys securely? – figlesquidge Jan 4 '14 at 10:30

Aman Raj's solution has a major drawback because I think it's not safe. When a user (say A) generate a session key and encrypts it with his private key, then anyone can decrypt the session key by using A's public key (since the public key is public to all). Here is my solution which I have tried.

Assume Alice and Bob wants to communicate and Trent is a server.

1. Alice or Bob requests Trent for a session key. Trent generates a random session key and encrypts it with both Alice's and Bob's public keys and send it to both.
2. Both Alice and Bob decrypt Trent's message to get the key, since they have their own private key with them.
3. Now they have a session key, which they can use to communicate with each other.

The success of this protocol depends on the total security of Trent because an intruder can hack into server and replace Alice's and Bob's public key with his/her own public key which will allow him/her to get session key. To avoid above this attack there is a protocol called Interlock Protocol.

-
There is also a drawback here, which is that the server knows the session key. This is not ideal, but there are better ways. For example, Alice could just request Bob's public key instead, and then she creates a session key, encrypts with Bob's public key, and sends this to Trend, and Trend just passes is on. Oh, and the users should create their private and public keys themselves and only give the server the public key in the setup. – tylo Jan 8 '14 at 14:39
@tylo but,letting users to generate session key faces one problem, both Alice and Bob should be capable enough to generate completely random session key!! – amanraj Jan 8 '14 at 15:02
Creating a random key is not that difficult, it does not even need the properties provided by CPRNGs - depending on the attacker model, ofc. But letting the server know the session keys is putting a lot of trust in this instance, it means the server (or anyone who can access its data) can listen to the entire communication. – tylo Jan 8 '14 at 16:47