Advanced cryptographic ratcheting
whispersystems.org
whispersystems.org
My favorite parts comes from combining of Diffie–Hellman operations on both long term and ephemeral keys to integrate identity verification and creation of deniable shared secret into one operation.
It's a really elegant extension of NaCL's secret box to include Perfect Forward Secrecy.
There are some things that are objectionable.
GPL licensing makes Open Whisper Systems a gate keeper to using the battle tested code base for most users. This is probably unnecessary. It isn't that hard to implement yourself giving a working curve library.
We need to better explain to developers with Ellitic Curve Crypto and Curve25519 aren't scary just because the math is a little unfamiliar and that RSA and integer field Diffie Hellman are code smell.
That's usually the sign of a good crypto design -- every bit of the message and computation is vital and can't be removed without everything else falling apart. Excessive round trips, duplicate fields, data sent twice -- these are all signs of a lousy design that probably has security flaws.
OTR always operated in a weird niche, but it solved a specific problem for IM that everyone had. But simpler / more elegant protocols don't always win, and never because of the quality of the crypto. For example: https://en.wikipedia.org/wiki/Simple_public-key_infrastructu...
I'd say that justifies some protocol complexity.
Deniability is almost a nice side effect of the asynchronous design. It doesn't seem like it adds tremendous complexity unto itself.
That would mean that checking the open sources they publish doesn't help as we don't know what they actually do on the server side.
Now I'd very much like to be proven wrong, so if anybody knows any independent work that claims that the protocols are made so that what's on the server doesn't matter, please post and I thank you in advance.
Also, does anybody know if the sources they publish are enough to make the fully independent infrastructure (run own servers)?
We don't have any mechanism other than trusting Whisper Systems that their client binaries matches the sources.
The truly paranoid could be their own client application from source.
And I'm not interested in the client side, but in the server side of the security. I assume I can rebuild the client using the sources and compare their client with my build.
What I can't assume is that their servers aren't, for example, infested by some state security malware which takes over the control. I want the protocols that work even when the server is subverted.
There are that are working on eliminating the need for central server for message delivery and key server roles like
https://whispersystems.org/blog/asynchronous-security/
"At registration time, the TextSecure client preemptively generates 100 signed key exchange messages and sends them to the server. We call these “prekeys.” A client that wishes to send a secure message to a user for the first time can now: - Connect to the server and request the destination’s next “prekey.”" Etc.
How is this not giving the server chance to insert its own keys and not the ones user generated?
What the QR code thing is actually doing? From what I understand, the TextSecure/Signal in one way or another send your contacts to the server and the server stores "prekeys" and delivers them to the clients. Where is any analysis that says that all this stuff doesn't mean that we have to trust that the server is not evil?
If the QR code means "yes it's the person you want to communicate to" but the contacts are on the server and the prekeys are delivered from the server, am I any better?
I need to read somewhere that the server is not weak point and why it is not. Any link?
Because the server can't sign the key exchange messages - the private key is generated on the client and never leaves it.
The protocol "safe from the server turning malicious" would also be good even if I'd run my own server to prevent Text Secure servers getting all the contacts.
It's possible for the server to hand out the wrong key for a user, but the clients detect that. There are other ways for users to mount impersonation attacks without server cooperation anyway.
The server also knows who talks to who, when, how big those messages are, and the number of attachments and their sizes. An adversary who can passively watch the server's encrypted traffic will also be able to determine some of these things, but not as easily or precisely.
All the TextSecure server is really trusted to do is a good job of confirming a user who purports to have a certain phone number really does control that number at registration time.
But that's how it is with any system. Even with PKI you're just trusting a different server. At least it's possible for you to check your contact's fingerprint out of band if you're really concerned.
You need the TextSecure server because without it you're not going to be able to connect to your contact at all. When everyone's moving between different connections to the internet and is almost always behind NAT then communication is only practical with a server.
There's nothing stopping anyone from exchanging messages directly over TCP sockets. It would totally work. But how practical is that? How will anyone initiate a connection to your cell phone?