nivkovic78

Not exactly. With SSL, encrypted communication goes between client and server. In case of this app, encryption is done with user's public keys, no server is involved in encrypting messages. Server role is only in signing public keys to ensure their authenticity. But that alone is bad and insecure practice.

"When a user is created and its public keys uploaded to the server, the server signs the public keys. Clients that download the public key then validate the signature of the key against the hardcoded server public key in the client. This ensures a MITM attack trying to use a rogue key pair to impersonate a user will be prevented."

This doesn't look good to me. Process implies trusting central server for cryptographic operations, which is very insecure. Central server should only be used as transport mechanism and should not be in any way involved in cryptographic operations that include working with secret keys. If someone, for example, seizes control of server (for government agencies this is an easy task, especially in these days) then he could forge user's public keys. The fact that public key is hardcoded in client application doesn't solve the problem either. What if server key is compromised? You'll have users with hardcoded compromised key in their app. Not a good situation. I see bunch of other security related problems in algotrithm description page also, but this one is crucial.