This isn't a great post for explain the simple elegance of Axolotol. There probably needs to be one.
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.
The reason it works so well is that Trevor started with the question "why is OTR so complicated?" and began removing parts until he had the minimum. Then, he looked at that and built a completely different protocol that achieved the same goals but where every part mattered.
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.
It would be a far simpler crypto design if it didn't insist on deniability as a feature.
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...
If I understand correctly, Open Whisper servers are still needed for TextSecure/Signal applications to work, there are even some initial keys involved, and if these servers were actually malicious, everything would be compromised?
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)?
Out of band verification of key fingerprints is necessary to protect against a malicious server. Users are encouraged to tweet their public keys and verify in person.
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.
Do you talk about TextSecure or PGP when you talk about "out of band verification of key fingerprints"? I'm talking about TextSecure.
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.
"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?
So would everything be safe if the server is controlled by an attacker and the attacker can also act as MtM for the communication data? Is there any analysis/verification of the full protocol and/or whole process of TextSecure/Signal as they are commonly used? I'd greatly appreciate the link.
The server code is available, people can and do run their own. Several other parties not affiliated with Whisper have written compatible clients. Lots of people are actively looking at and contributing to the official clients. It really is private end to end. The server is merely a router and keyserver.
If I understand, somehow the server delivers the initial keys to clients ("to make the process easier"). What happens if some evildoer takes control of Text Secure servers? Can the evildoer read all the communication from that point on, provided he can also capture the encrypted traffic (which is reasonable to assume)?
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.
The server has the keys in roughly the same way a PGP keyserver has the keys. They're all public keys, and they would be sent in the clear anyway, however storing them with the server enables senders to send to recipients who are offline. The server can't make use of them to read any communication.
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.
So if the server is under the control of the attacker and I use TextSecure expecting to "just work" (not already having the private key of my contact) I can actually communicate with the attacker instead of with my contact? And if I already have the private key of my contact, why do I need the TextSecure server at all?
You never have the private key of your contact. Private keys are private. But I get what you're saying. The system is trust on first use, so your client will accept whatever the server gives you as the identity.
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?
18 comments
[ 3.0 ms ] story [ 45.8 ms ] threadMy 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://briarproject.org/
https://github.com/muttr/whitepaper/blob/master/README.md
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?