2
$\begingroup$

I am using a PGP method to encrypt and decrypt messages shared between users A and B.

Upon the start of a message exchange is the initialization of the public and secret keys by both Users.

Lets say that User A downloads the message exhange app and he adds his friend (through phone number). He then wants to initialize a conversation. At this point User B has still not downloaded the app.

How are the keys to be safely generated if it is User A initializing the conversation? Technically, the request of creating the secret key for both parties would then have to be done by User A as well, which makes it not safe.

Without the public key of User B (thus also the creation of the secret key for User B), User A will not be able to start sending encrypted messages.

The obvious solution is that he will need to wait before the friends accepts the friend request, thus creating and sharing the keys.

Is there a way to solve this issue without this restriction? That is, how can User A already start sending encrypted messages to User B, who has not signed up and accepted the request?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
1
$\begingroup$

You could use message specific keys, which encrypt the messages themselves. Once a secret key has been established you can encrypt the message specific keys with it and send them over in a new message (with meta-data) to user B. You should of course have some method of storing the encrypted messages somewhere for this to work.

Improve this answer
$\endgroup$
5
  • $\begingroup$ PS. I'm not going into establishing the trust relationship, that can be solved in multiple ways (using a PGP key server for the web-of-trust would probably be most logical method of doing this). $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 28, 2015 at 0:22
  • $\begingroup$ Is there a specific method that is common used? $\endgroup$
    – WJA
    Commented Oct 28, 2015 at 21:44
  • $\begingroup$ I've only seen this approach but it doesn't get asked much. Usually the key exchange or agreement is in advance. $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 28, 2015 at 22:48
  • $\begingroup$ Do you know any tutorials or documentation that can elaborate it in more detail? Or perhaps the definitions that I should be looking at? $\endgroup$
    – WJA
    Commented Oct 28, 2015 at 22:57
  • $\begingroup$ Heh, no. It's hard enough to remember all the crypto tricks without remembering where I learned about them. $\endgroup$
    – Maarten Bodewes ♦
    Commented Oct 29, 2015 at 0:00
1
$\begingroup$

Typically a few methods of establishing a shared secret (temporary or permanent) requires at least two active parties to be online at the same time to do the key agreement live. What Maarten proposes is to simply store a draft message secured somewhere only User A can access until User B gets to finalize a shared secret with User A then is the secured message transferred to User B using the established shared secret.

Two common approaches with the first one being a direct key exchange between User A and User B (both online at the same time and reachable) is the most simple method. Another approach is called Key Escrow which means you put your trust in a third party to safe keep or mediate but that means you would be vulnerable to an additional party. For the Key Escrow to work, the Key Escrow must be online as a "crypto proxy" and you exchange keys with the third party to send an escrowed message and assign User B the permission to retrieve it (you have to design your own permissioning system) once User B registers successfully for the service. Do note that Escrow is one of the worst ideas if you do not control that third party system personally and physically (it has huge inherent risk if it fails).

Improve this answer
$\endgroup$

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.