BTW, this code would have trouble sending messages between locales. I had a quick look at the encryption code, and found this:<p><pre><code> public static String sign(PrivateKey privateKey,
String data, String derivedPassword) {
return sign(privateKey, data.getBytes(), derivedPassword.getBytes());
}
</code></pre>
... which of course uses the current platform's character set, not a consistent one across platforms. Definitely not what you want in this kind of application (unless Android is UTF-8 in all countries? I don't code for it). That was in this class:<p><a href="https://github.com/surespot/android/blob/master/src/com/twofours/surespot/encryption/EncryptionController.java" rel="nofollow">https://github.com/surespot/android/blob/master/src/com/twof...</a><p>...but someone making a mistake with getBytes() usually does it everywhere.
"Only the person you send the message to can read it. Period."<p>To use this kind of sentences on new software not reviewed by the comunity is dangerous. There is people that risk their lifes using this kind of app.<p>The thing that puzzles me is that sentence:
"You can delete your message from the receivers phone."
I don't see in the 'how it works' any information about it. Do they do that in a cryptographic way somehow that I can not imagine? Or is basically that the application removes the content if the server request it, something we could avoid just with a backup or modifying the code of the app.
<i>You can delete your message from the receivers phone.</i><p>That second bullet point set off my BS detector (and is where I stopped reading). No system on earth lets you <i>reliably</i> delete a message sent to another device over the Internet, after the fact. Neither can any such system reliably prevent users from sharing pictures that they can see on their device.<p>This site reads like an add for a perpetual motion engine.<p>Which is too bad, because open-source encrypted mobile chat is an interesting thing in and of itself, without impossible pie-in-the-sky claims.
"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."<p>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.
Also check out <a href="https://threema.ch/en/" rel="nofollow">https://threema.ch/en/</a> - it has the same functionality as WhatsApp (except of group chat), but secure/encrypted and is available for Android and iOS.<p>They're using the NaCl library for cryptography and proper encryption of messages before leaving the phone can be validated here: <a href="http://threema.ch/validation/" rel="nofollow">http://threema.ch/validation/</a><p>(I'm not affiliated with Threema, just a regular user who likes the product)
First impression:<p>* No details of threat model<p>* No details of crypto protocols used<p>* No discussion of how key exchange problem is solved<p>* Makes misleading security claims "when you delete a sent message it will be removed from the receivers phone"<p>Basically falls into "don't touch with a barge pole" category of crypto software.<p>Crypto software isn't a category where you can make it up as you go along, it has to be designed upfront with a set of security considerations for it to have a chance of survival in the real world.