public static String sign(PrivateKey privateKey, 
         String data, String derivedPassword) {
        return sign(privateKey, data.getBytes(), derivedPassword.getBytes());
    }

https://github.com/surespot/android/blob/master/src/com/twof...

...but someone making a mistake with getBytes() usually does it everywhere.

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.

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.

Recently I read a whitepaper where a security tester was talking to a malware author on Skype. The author mentioned an IP address and deleted it moments afterwards. The researcher dumped their ram into a file and searched for the string (successfully).

It is open source, so at least it is trivial to create a clone that interops flawlessly, while copying off plaintext to a third party (That's not a flaw with the project as such, but it is a risk with using "security" software in general -- how do you verify the security software? In some ways this is made worse by app stores -- because they delegate trust away from the user and into obscurity; the appstore assures you that the app you installed is the app someone uploaded -- not that it does what you think it does).

It is also false, since it seems that their threat model also includes the server being able to transparently MITM you and read all your messages. A pretty egregious overstatement, I think.

That second bullet point set off my BS detector (and is where I stopped reading). No system on earth lets you reliably 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.

This site reads like an add for a perpetual motion engine.

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.

> Be confident sending private information and pictures.

... be confident? That kinda implies it's reliable enough to be confident in it.

Of course you can take a screenshot of the image, but they have figured out how to capture that event and it alerts the sender.

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.

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.

Conversely if you're actually interested in protecting your information, then client-side encryption with self-authenticated keys has always been the only solution.

They're using the NaCl library for cryptography and proper encryption of messages before leaving the phone can be validated here: http://threema.ch/validation/

(I'm not affiliated with Threema, just a regular user who likes the product)

* No details of threat model

* No details of crypto protocols used

* No discussion of how key exchange problem is solved

* Makes misleading security claims "when you delete a sent message it will be removed from the receivers phone"

Basically falls into "don't touch with a barge pole" category of crypto software.

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.

details of threat model- https://www.surespot.me/documents/threat.html

details of how surespot works including crypto- https://www.surespot.me/documents/how_surespot_works.html

you can always review the code on GitHub- https://github.com/surespot/android

https://www.owasp.org/index.php/Threat_Risk_Modeling

To understand the standard approaches to threat modelling.

It should be trivial for someone to look at the documentation and quickly answer basic security questions like "Does it defend against replay attacks ?" and "Does it leak message size ?"