3
$\begingroup$

$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?

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ I think you are looking for a mix net with a single proxy. $\endgroup$
    – DrLecter
    Commented Jan 3, 2014 at 9:56
  • $\begingroup$ Can't we establish secret keys between A,server and Server,B? $\endgroup$
    – deltaaruna
    Commented Jan 3, 2014 at 11:13
  • 1
    $\begingroup$ It sounds like you mean 'origin of the' rather than 'original' in your first sentence? $\endgroup$
    – Cryptographeur
    Commented Jan 3, 2014 at 11:27
  • 1
    $\begingroup$ This sounds like the requirements for Tor $\endgroup$
    – Maarten Bodewes ♦
    Commented Jan 3, 2014 at 12:00
  • $\begingroup$ 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. $\endgroup$
    – tylo
    Commented Jan 8, 2014 at 14:32

2 Answers 2

Reset to default
1
$\begingroup$

  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.

Improve this answer
$\endgroup$
2
  • 4
    $\begingroup$ 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. $\endgroup$
    – Cryptographeur
    Commented Jan 3, 2014 at 12:53
  • 1
    $\begingroup$ I notice you corrected the final paragraph, but it's still unclear how you envisage the server distributing private keys securely? $\endgroup$
    – Cryptographeur
    Commented Jan 4, 2014 at 10:30
1
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • 1
    $\begingroup$ 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. $\endgroup$
    – tylo
    Commented Jan 8, 2014 at 14:39
  • $\begingroup$ @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!! $\endgroup$
    – amanraj
    Commented Jan 8, 2014 at 15:02
  • $\begingroup$ 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. $\endgroup$
    – tylo
    Commented Jan 8, 2014 at 16:47

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.