0

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.

Discussion:

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.

Note:

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.

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?

Angelica
  • 1
  • 2
  • This protocol lacks perfect forward secrecy and break-in recovery. See https://security.stackexchange.com/questions/256443/in-a-synchronous-environment-does-signal-offer-any-security-benefits-that-can-t for a related question. – mti2935 Aug 23 '22 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 Aug 23 '22 at 18:10
  • @JohnWu I added message authentication to the protocol and also addressed the key-rotation and password recovery concerns. – Angelica Aug 23 '22 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 Aug 23 '22 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 Aug 23 '22 at 18:42
  • @JohnWu Also, here's a wild assertion: not doing key-rotation is just like not buying a new device every now and then. In the Signal protocol, if you lose your device, you lose control over your data, just like if you were to lose control over your key in this protocol. – Angelica Aug 23 '22 at 18:47
  • We're trusting the server now? Why is any of this necessary then? – John Wu Aug 23 '22 at 18:56
  • @JohnWu We're only trusting the server regarding correctness and authenticity of user data and public key data, not regarding the contents of our messages. Does that make sense and isn't that the case with the Signal protocol as well? – Angelica Aug 23 '22 at 18:57
  • OP and @JohnWu - Actually, Signal has the same problem. Users that want to authenticate other users' public keys must do so using some out-of-band method. Signal has something called 'safety numbers' to help facilitate this process. See https://security.stackexchange.com/questions/139596/signal-protocol-implementations-pub-key-authentication-and-inspectability-all for more info. – mti2935 Aug 23 '22 at 19:18

1 Answers1

2

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.

foreverska
  • 1,115
  • 11
  • 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 Aug 23 '22 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 Aug 23 '22 at 16:26