CODEWITHSUNDEEP
encryptionstorageprivate-keyopenpgp
RoboCop
RoboCop

Reputation: 96

Private key storage issue in OpenPGP encryption

I'm trying to implement OpenPGP end to end encryption on a simple messaging app which will be accessed on the web as well as mobile. I'm stuck at deciding where my private key should be generated and stored. The following two approaches are on the table(i don't want to go with approach 2 but that looks like the only feasible option) :-

Key storage approach 1:-

  1. When the user logs into the Chat client the first time, the client (web/app) will generate a set of public and private keys.

  2. The user's public key will be sent to the backend server. The user's private key will be encrypted and stored on the local storage of the client.

Problems with this approach:-

Key storage approach 2:-

  1. When the user is created on the backend server, create both public and private keys for the user using PGP on the backend itself. Public key can be stored in plain-text but the user's private key should be encrypted and stored. We can use symmetric encryption with a client-specific passphrase here.

  2. When the user logs into the Chat client (web/app), the encrypted private key will be received from the backend upon login. In order to decrypt any message, then can decrypt their private key using their passphrase, then use the private key to decrypt the message received.

Problems with this approach:-

Upvotes: 0

Views: 533

Answers (1)

Frederick Nord
Frederick Nord

Reputation: 1324

Reg. approach 1: If the client hasn't had the opportunity to share their public key, then indeed, you cannot send encrypted messages. It's unclear how you would solve that problem. The private key you can encrypt with a passphrase and upload the encrypted version to your backend so that the client can then download it and have it available on other devices, as you write in your second approach. Or you can go a step further and generate the private from the passphrase.

Your approach 2 may actually not have much worse security properties, depending on how you look at it. You could argue that you have no infrastructure anyway to let clients make sure they have obtained the correct key material. So they cannot distinguish the actual public key of the user from a malicious one provided by the server.

How you design your system is up to you, of course. I suggest you start laying out your requirements. Your problems seems to become smaller if not-yet-known users do not need to receive encrypted messages.

Upvotes: 0

Related Questions