Signal Messenger is basically state of the art chat when it comes to security and privacy: It uses only phone numbers for user identification, doesn't store user chat and the encryption protocol is tried, tested and proven. It is very sophisticated especially in regards to its encryption protocol.

But why wouldn't the following, simple chat app protocol be secure enough?

Note: I addressed the authentication concerns and added message authentication to the protocol. The goal is to find the simplest, minimum viable protocol.

User creation:

  • A user picks a strong password and creates a public/private key pair.
  • The private key is encrypted using the password, for example using PBKDF2.
  • The encrypted private key and the public key are stored in the server.
  • Furthermore, a signing key pair is created for the user and the verification key stored on the server.

Secure message exchange

  • Alice and Bob exchange their signature verification keys by retrieving them from the server.
  • Alice creates a symmetric encryption key.
  • Alice gets Bob's pubkey from the server.
  • Alice uses Bob's pubkey to encrypt the symmetric key.
  • Alice signs her message using her signing key and appends the signature to the message.
  • Alice encrypts her now signed message using the symmetric key.
  • Alice sends the encrypted message along with the encrypted symmetric key to Bob.
  • Bob uses his private key to decrypt the symmetric key.
  • Bob uses the symmetric key to decrypt Alice's message.
  • Bob uses Alice's verification key to verify the signature stemming from Alice.


There seems to exist no feasible attacks that can compromise above protocol (apart from social engineering or stealing a device). Private keys are never sent across the wire in plain text. Given a strong password that is used during encryption, it is virtually impossible to decrypt a PBKDF2-encrypted private key. Furthermore it is important to note:

  • Like the Signal protocol, this protocol is made for client <-> server <-> client communication which entails that the server is assumed to be a trusted component. Any public keys or data are retrieved from the server and trusted.
  • One compromise made here is that a lost password means loss of all data. This is, however, similar to losing your device with the Signal App, which would likewise result in loss of all data.
  • Another concern raised is that the keys are not rotated in my protocol. However, I believe this is easily fixed by simply recreating new keys and re-encrypting all data every fixed time interval.


Please do not discuss PBKDF2 vs any other methods. It is simply a placeholder for that type of method and not the subject of this question.


Why is anything more complicated than the above-described protocol ever needed - such as the complex, complicated, quadruple-ratchet Signal protocol which I don't understand with my basic cryptography knowledge - when it comes to simply exchanging messages in a secure manner?

  • This protocol lacks perfect forward secrecy and break-in recovery. See security.stackexchange.com/questions/256443/… for a related question.
    – mti2935
    Commented Aug 23, 2022 at 15:24
  • At first blush this seems vulnerable to man-in-the-middle, replay attacks, and impersonation (you are not authenticating Alice). Also, there is no facility for rolling the keys or recovering a lost password.
    – John Wu
    Commented Aug 23, 2022 at 18:10
  • @JohnWu I added message authentication to the protocol and also addressed the key-rotation and password recovery concerns.
    – Angelica
    Commented Aug 23, 2022 at 18:37
  • "Alice and Bob exchange their signature verification keys.." Can you provide more details? How does Bob verify Alice's identify during the key exchange? Bearing in mind you have not yet established a secure channel at that point in the process.
    – John Wu
    Commented Aug 23, 2022 at 18:37
  • @JohnWu Oh those keys are stored on and retrieved from the server so obviously this protocol relies on trusting the server.
    – Angelica
    Commented Aug 23, 2022 at 18:42

1 Answer 1


I don't have enough time in my day to read up on how signal approaches this but the first issue off the bat with this scheme is a lack of forward secrecy. A compromise of Bob's private key at any time will expose all of the messages sent to Bob.

I know you have waved away stealing a device but a properly designed cryptographic protocol is not weak to single key exposures.

A further quibble:

In this scheme specifically you have forgotten to sign it as Alice, so Bob has no assurance this came from Alice and not his arch rival pretending to be Alice hoping to embarrass Bob by standing him up publicly.

  • Say I add this: A user creates a signing key pair at registration. Before texting, A and B exchange their respective verification key. A signs her message using her signing key. B authenticates the message using A's verification key to verify the signature on it, before decrypting the message. Is that enough to at least solve the authentication problem you mention? Thanks for your answer.
    – Angelica
    Commented Aug 23, 2022 at 15:31
  • I believe it is customary to sign plaintext, append the signature and then encrypt the whole thing but otherwise you have the idea.
    – foreverska
    Commented Aug 23, 2022 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .