Why is this simple encryption protocol not enough for messaging?

Question

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?

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.