"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.
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.
That "Signing public keys to ensure their authenticity" is exactly what (any of the possibly as many as 600) public CA's that your browser and/or OS come pre-configured to "trust".
Who the hell are "Xramp Global CA"? "VRK Gov Root CA"? "UCA Root"? "Trusted Certificate Services"? They're all just random selections from the first page of trusted root certs in this OS X machine's list of System Root keys. Any of them could choose to "authenticate" a public key that claims to be my bank. Apart from the few pinned certificates in Chrome (I think mostly Google certs), I've got no more reason to believe any SSL connection I make is "authenticated" any more than Iranian Gmail users should have had when a DigiNotar root CA cert had signed those rouge Google SSL certs.
It also used to "secure" your email communication with Lavabit… And the 8 (alleged) PRISIM participants. From what I read – "trusting the legal system for that" perhaps isn't a particularly prudent idea.
If the government doesn't want to recognize the value of your money, they don't need to snoop on your communications with your bank to do it.
Conversely if you're actually interested in protecting your information, then client-side encryption with self-authenticated keys has always been the only solution.
Comments
"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.
FWIW, that's exactly what happens with Verisign (or DigiNotar) when you connect to your banks SSL website…
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.
That "Signing public keys to ensure their authenticity" is exactly what (any of the possibly as many as 600) public CA's that your browser and/or OS come pre-configured to "trust".
Who the hell are "Xramp Global CA"? "VRK Gov Root CA"? "UCA Root"? "Trusted Certificate Services"? They're all just random selections from the first page of trusted root certs in this OS X machine's list of System Root keys. Any of them could choose to "authenticate" a public key that claims to be my bank. Apart from the few pinned certificates in Chrome (I think mostly Google certs), I've got no more reason to believe any SSL connection I make is "authenticated" any more than Iranian Gmail users should have had when a DigiNotar root CA cert had signed those rouge Google SSL certs.
That's for communicating with your bank. If you can't trust your legal system for that, then you have much bigger problems.
It also used to "secure" your email communication with Lavabit… And the 8 (alleged) PRISIM participants. From what I read – "trusting the legal system for that" perhaps isn't a particularly prudent idea.
If the government doesn't want to recognize the value of your money, they don't need to snoop on your communications with your bank to do it.
Conversely if you're actually interested in protecting your information, then client-side encryption with self-authenticated keys has always been the only solution.