1
$\begingroup$

A bit of a general question from someone who is pretty much a rookie when it comes to cryptography:

So I have an app where users are able to chat with each other 1-to-1 (no group chats). Currently the app stores all messages as plaintext in the db for backup, so that each time a user connects to the chat they are synced with what is in the db. I would like to figure out how to store the messages in the db in a way that they are only readable by either of the participants in the chat.

Could you guys point me in the right direction in terms of what type of encryption to use? Is Public Key Cryptography suitable for this use case?

$\endgroup$
1
$\begingroup$

There are two solutions which vary in their integration complexity but also in their feature-set.

Solution 1: The Signal Protocol

The Signal Protocol is, well, the protocol used by the famous Signal-Messenger and which was also adapted in quite a few other popular messengers such as WhatsApp. It is designed to perform best in the situation you're in: asynchronous chat applications. As such it ensures forward secrecy and allows to confirm other parties at any point. As a bonus there's the famous libsignal which should greatly ease implementation.

If you can this is absolutely the solution you should take.

Solution 2: E-Mail Encryption methods

If however integration of the Signal Protocol proves impossible for your deployment, the usage of standard E-Mail encryption methods should still work. Basically you let each party generate public-private keypair(s) and then use your favourite PGP encryption and signing library to sign and encrypt the message as if they were emails or you could use your favourite S/MIME library to do the same. However this doesn't provide forward secrecy and gives non-repudiation to the messages (ie "everyone" can verify that X send the message Y). Key confirmation can be solved by your provider (for when the users trust you) and by comparing key hashes by the users if they meet in person.

This is the second best solution which you should implement if the Signal Protocol really isn't an option.

$\endgroup$
  • $\begingroup$ Awesome, thanks a lot! The Signal Protocol seems like the right solution for my case $\endgroup$ – Juuso Feb 20 '17 at 12:30
  • $\begingroup$ @JuusoLappalainen I would strongly council you away from Signal. Do not use it. From cursory research, Signal uses a Double Ratchet Algorithm, prekeys, triple Diffie–Hellman (3-DH) handshake, and Curve25519, AES-256 and HMAC-SHA256 as primitives. It reads like Saturday's Bundesliga results to me. And you're throwing in a database too. Those are all primitives. You have to put them all together. As a self confessed rookie, can you guarantee that you can do it securely? And if you say you can, who is going to test it to prove otherwise? You'll never know... $\endgroup$ – Paul Uszak Feb 20 '17 at 22:50
  • $\begingroup$ @PaulUszak the idea behind the Signal recommendation was to encourage the usage of the existing, tested and hardened libraries. Of course I'd strongly recommend against implementation of either of these approaches yourself. The idea also is that you use the database merely as a transport medium. $\endgroup$ – SEJPM Feb 20 '17 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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