
Surespot app - free and open source encryption for everyone - clicks
https://www.surespot.me/
======
bazzargh
BTW, this code would have trouble sending messages between locales. I had a
quick look at the encryption code, and found this:

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

... 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:

[https://github.com/surespot/android/blob/master/src/com/twof...](https://github.com/surespot/android/blob/master/src/com/twofours/surespot/encryption/EncryptionController.java)

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

~~~
bazzargh
Just thinking about that - this class of error gets reported by Findbugs and
other static analysis tools. So, this bug indicates that there aren't tools
like that in the build - for a security app, where correctness should be top
priority, that's surprising.

------
meskio
"Only the person you send the message to can read it. Period."

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.

~~~
StavrosK
> "Only the person you send the message to can read it. Period." > 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.

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.

~~~
surespot
The threat model also suggests that you verify key fingerprints manually if
you are concerned about MITM.

~~~
StavrosK
Yeah, I guess verifying the full length of the fingerprint would mitigate
that, and not doing that exposes you to a MITM attack anyway. Not much less
secure than exchanging the keys directly, then, you are right.

------
veidr
_You can delete your message from the receivers phone._

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.

~~~
StavrosK
Well, they didn't say "reliably". Many apps do this on a best-effort basis,
it's usually good enough but people shouldn't trust it too much.

~~~
kivikakk
Sure, but it's the #2 bullet-point on their home page, and they don't use the
word reliably, but:

> Be confident sending private information and pictures.

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

------
nivkovic78
"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.

~~~
bigiain
FWIW, that's exactly what happens with Verisign (or DigiNotar) when you
connect to your banks SSL website…

~~~
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.

~~~
bigiain
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.

------
znq
Also check out [https://threema.ch/en/](https://threema.ch/en/) \- it has the
same functionality as WhatsApp (except of group chat), but secure/encrypted
and is available for Android and iOS.

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/](http://threema.ch/validation/)

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

~~~
devx
I think Tox.im uses NaCl, too, but it's for PC only right now (it's new).

------
ig1
First impression:

* 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.

~~~
surespot
Perhaps you can get a second impression-

details of threat model-
[https://www.surespot.me/documents/threat.html](https://www.surespot.me/documents/threat.html)

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

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

~~~
ig1
You should have a look at:

[https://www.owasp.org/index.php/Threat_Risk_Modeling](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 ?"

------
hnha
Only everyone on Android. Sadly my friends use ios and windows, so we have to
wait.

