TextSecure's Private Group Messaging
whispersystems.org
whispersystems.org
1. What is TextSecure's business model? Who pays for the server infrastructure?
2. Doesn't WhisperSystems belong to Twitter? Twitter is a US-company (and also part of the NSA stuff), so why should I use that kind of software? [Edit for clarification: I'm from Germany, where the US/Twitter affiliation is seen as a downside by some people].
It would be great if TextSecure/Open Whispersystems publicly addressed these points. I have seen that there's a reply from Moxie here: http://support.whispersystems.org/customer/portal/questions/...
but these two questions are so central that they deserve more attention than a reply in the support forum. From a technological point of view, TextSecure wins hands down. Now it's time to convince those who are still skeptical because of other reasons.
Just to be clear: I want TextSecure to become successful. I'm a big fan. That's why I'm mentioning this: in order to help spread the word.
Besides, TextSecure is free software so it might possible to run your own server at least in the future.
(I don't know if that would be feasible, but I suppose that's what avn2109 meant).
[ie: not a timing attack, but traffic analysis]
In this case, it seems like that metadata would 'just' be the time you sent and received messages from the server. Depending on how Google's push protocol works.
So for the average person that would be fine, but if you were seriously annoying a government that was in bed with your phone company, they could probably figure out who was a part of your cell by the timing of your sent and received messages.
[1] http://support.whispersystems.org/customer/portal/articles/1... [2] https://github.com/WhisperSystems/TextSecure-Server
Note, the page confirms: Google Play still has to be installed to use TextSecure on Android. That is the current state. Google has practically the root access to the every Android device which runs TextSecure.
Apple also has root access to all iOS devices via their over-the-air update framework. Opaque basebands and graphics chips with closed source drivers are difficult to trust too. None of these scenarios mean that software which offers serious improvements over the status quo should be casually dismissed. TextSecure can (and does) provide significant protection from mass surveillance and targeted surveillance. Security nihilism is corrosive.
What you call "nihilism" is simply the observation of the current state. At the moment Google has root access and all the metadata of all TextSecure users, and currently the user can't configure TextSecure to use some other servers even if he'd prefer to do so. Still I'm glad that I've seen that some server-side code is now open source.
Google does not have access to any metadata, other than the fact that you are a TextSecure user who has received a Push notification. GCM payloads are fully encrypted. Google cannot tell who a message was from, they cannot see which numbers were involved (users are free to register with a number that is different than the one assigned to the cell phone that is running TextSecure), they cannot tell whether or not it was part of a group conversation, and they cannot see its contents.
> Whisper Systems was a company focused on the development of mobile security software, which was acquired by Twitter in late 2011. Twitter very generously made some of the Whisper Systems software available under an Open Source license (GPLv3), which has since been under open development by the community. The software has seen a number of new releases based on that open development, and we’ve been calling the project for this continued work “Open Whisper Systems.” Welcome to the project’s new home.
It's a good question. TextSecure is not a business, so we don't really have a business model in the traditional sense. Open Whisper Systems is a collective project made up of volunteers and a growing number of contributors, who are sometimes paid by donations (https://whispersystems.org/blog/bithub/) and grants.
Thus far, we've been able to smoothly fund the server infrastructure through grants and donations as well. I think we'll probably be able to continue that way indefinitely, but if that ever changed for any reason, we would consider charging small amounts for premium or high cost features like extremely large attachments. But in general, Open Whisper Systems is a project rather than a company, and the project's objective is not financial profit. I know that's a difficult thing to explain.
> 2. Doesn't WhisperSystems belong to Twitter? Twitter is a US-company (and also part of the NSA stuff), so why should I use that kind of software?
This is also confusing, but Open Whisper Systems is not Whisper Systems. Open Whisper Systems has no relationship with Twitter at all, and is a different organization that came together to facilitate development of the Whisper Systems software which was released under GPLv3. Twitter has never contributed money or resources to Open Whisper Systems, and is not in control of any of the infrastructure.
I'd pay even more good money for hosting to not be in Google's data centers.
The TextSecure servers are not hosted in Google's data centers. Google's GCM push messaging framework is used to deliver messages to Android users, but the GCM payloads are fully encrypted.
- You can run your own server
- Your server cannot talk to the 'official' servers
- Federation is somewhat possible, but works on a 'We whitelist your machine' base
It's not XMPP. So people using 'Default' TextSecure and your friends & family on your own TextSecure server would be isolated, as far as I understand.
I'd love to be corrected though, because THAT (not business model/jurisdication) is my reason why I'm not comfortable using/recommending it. No offense to moxie and his team, but for me this is another Threema unless running under my (most likely not competent enough, if we're honest) supervision.
I can't wait for WhisperSystems to release the iPhone version of the app -- at that point, all my family's communications will go through TextSecure.
Or is anyone aware of a secure group chat application to replace IRC (or SILC for that matter)?
Your second question is harder. I don't know of a better solution than a self-hosted jabber-server with https.
But I wish it didn't send my contact list to its servers and store them in perpetuity [1]. Has it be considered to use:
1. text message history with a contact to derive a key between two contacts?
2. adding metadata to text messages to discover the sender uses TextSecure?
By (1), I mean Alice and Bob may already have exchanged several messages. I believe there is a lot of entropy in text messages. That should be leveraged during the key exchange. In addition, you'd also use WhisperSystems's servers as another channel, so the mere possession of the text history doesn't allow an attacker to guess the key.
(2) would only be useful when Alice sends her first text to Bob. She would for example hash(text_message + "I use TextSecure"), then append the encoded hash to the text and finally send it. The encoding could be white spaces for 0 and tabulations for 1. The size of the hash could be as small as 8 bits, because adding 8 trailing spaces/tabs to a text is so rare in real life. Once Bob receives the text, he can reasonably assume Alice uses TextSecure and then start the regular key exchange.
The client sends a truncated hash of each contact to the server, and the server responds with the set of matches. The process does attempt to protect your privacy, however the "preimage space" is small, and the server will accept thousands of contacts per directory update so enumeration of TextSecure users is possible. The directory update process occurs every 12 hours.
The TextSecure-Server does not store these hashes of your contacts. Of course, we can't know for sure what any particular instance does. It could be modified to log that info.
Metadata is in fact added to text messages to discover other TextSecure users. You can exchange encrypted messages over SMS and MMS with users who are not registered on the server or with users who are registered on another server.
Do you mean that TextSecure may send encrypted messages to contacts who don't have it?
You didn't address my bullet (1). If Alice has exchanged N texts with Bob prior to installing TextSecure, these messages could be used to make the preimage space huge.
Texts have a lot of entropy. From an scrypt slide "Entropy estimated according to formula from NIST: 1st character has 4 bits of entropy; 2nd–8th characters have 2 bits of entropy each; 9th–20th characters have 1.5 bits of entropy each; 21st and later characters have 1 bit of entropy each". So a 140-character text has about 156 bits of entropy, excluding the date the text was sent which probably adds some 20 bits.
It's too bad not to use that both during the discovery and the key exchange.
Same thing for RedPhone, it could leverage the call log between Alice and Bob.
Of course not. The recipient would see unreadable ciphertext. What I'm saying is that SMS carries some metadata which identifies the message as coming from TextSecure. This enables one TextSecure client to detect the presence of another without the TextSecure-Server, and offer the option of establishing a secure session. In this case key exchange is performed over SMS.
I'm not sure I understand your first bullet point. The preimage space of what? In what way do you propose to use the entropy of text messages or call logs?
TL;DR: TextSecure faces a key distribution problem. But texts messages are somewhat secret and are often already stored in each of Alice and Bob's phones. My assertion is these secrets authenticate Alice to Bob and Bob to Alice.
I mean currently it's easy to reverse a hash because there aren't many phone numbers (that was your point, wasn't it?). If you query WhisperSystems (WS) by hash(sender_number + recipient_number + date_sent + text_message), then the hash is much harder to reverse for any long text message. Alice and Bob can both compute the hash and discover whether the other has TextSecure because only they can query this hash to WS. Similarly, they can authenticate each other and exchange keys because only they know their past message history.
Obviously, you wouldn't use text history alone because someone may have been eavesdropping. But these distributed secrets would make WS know much less about its users and could help bootstrap the PKI in my opinion.
The problem I see with using text messages for that is that Alice and Bob very likely have not exchanged messages before. Or they have but those messages are no longer on the device because they have been deleted. Or Bob just bought a new device.
A variation of the idea is using the contact name. It's more reasonable to expect the sender to know the name and address of the recipient, but that has problems too: It would require the sender know the exact spelling of the recipients name (eg. Robert? Bob? Rob?) Also, while hash(name + address) is harder to crack than hash(address) it's not that hard for anyone who knows the value of address. The server knows this, so the server operator would be in a position to figure out names for nearly everyone. The server would also function as an oracle for anyone who knows a number and suspects a name, or knows a name and wants to scan for the number. That's even worse than allowing for enumeration of registered addresses.
Does that make sense or am I missing something?
I disagree about the likelihood that messages or phone calls were exchanged prior to installing TextSecure. And restoring the SMS database after purchasing a new device is not impossible. But I agree that names and addresses wouldn't work, although I didn't suggest so.
My point was that it would improve on the status quo, at least for people you care most about (the ones you've talked to, the texts you didn't delete). And once the hashes are hard enough to reverse, you can have a federation of TS servers, because it becomes less risky to share them with an untrusted party. Maybe the improvement would only be marginal after all.
Anyway thanks for the discussion.
Neither is comparing key fingerprints, but 99% of users are unwilling to do so.
> Anyway thanks for the discussion.
Looking at the docs and blog posts may give you the impression that certain things are done, when in actuality they're not.
For example, the TextSecure-Server does include federation related code, but implementation is definitely not complete yet. It's not clear to me whether or not all design decisions have even been finalized yet.
I encourage you to write up your idea more formally and post it on the WhisperSystems mailing list. Just don't wait too long, or Moxie and his gang of contributors will just decide what to do and push working code before you know it!
Can someone knowledgable comment about the crypto protocol here and how this provides guarantees that ensure the server can't reverse the messages for multicast (am happy to read academic papers here too)?
> Anyone can create a group, name it, give it an avatar icon, add members, and then everyone can chat together with a normal asynchronous experience.
Does this mean that any group member can add more members? Are there any IRC-like moderation features (even planned?), eg. privileged members who can remove users from group? Is there support for persistent groups (ie IRC channel equivalents)?
A group conversation persists locally on your own device unless you delete it, just like a normal conversation. The server does not store any records representing the group, so there's nothing to persist beyond the clients.
There is no plan to change these properties, afaik.
Consider a group chat between Alice, Bob, and Carol. With this protocol, Alice can selectively send different messages to Bob and Carol with both of them thinking they got the same message.
For example, Alice can tell Bob "The funds were transferred, thanks!" and tell Carol "Bob is stealing money." — and the protocol will ascribe integrity to the messages for both participants and label them as the same message.
That said, I strongly respect Open Whisper Systems. They usually release very well thought-out material. Perhaps they should have paid more attention though to this particular issue.
mpOTR, on the other hand, only shows transcript consistency at the end of a group chat session. This does seem problematic.
Further, it's hard to understand how transcript consistency could be a serious objection while lack of forward secrecy in the messages isn't, especially given the deniable messaging semantics of OTR.
So, to address your concluding sentence directly: it seems to me like Moxie has paid more attention to this issue than you have.
And yes — I believe my work on Cryptocat does grant me some helpful perspective on the kind of issues faced in group chat. I'm more than happy try my best to offer some insight to other great open source projects. If I wanted to sneakily hide that I work on another encrypted messaging project (why would I? Open source projects discuss issues with one another all the time) it would have been simple for me to create another username.
https://hn.algolia.com/?q=author%3Akaeporan#!/comment/foreve...
I am, however, happy to attack your project, Cryptocat, which I believe to be incompetently interviewed, debugged into existence, and dangerous to its users.
Finally, you still haven't responded to my comment upthread.
The TextSecure protocol retains forward secrecy at the message layer and provides continuous transcript integrity. The TextSecure client hasn't worked out the UI for it, but the protocol supports it. TextSecure can provide continuous transcript integrity with a UI update --- something mpOTR clients can't do at all.
But here you are, sniping at TextSecure for lacking a UI feature that you've implemented a minimal and un-useful version of. Then, when called on it, you retreat to a position of "I'm inspired by TextSecure and am just trying to help". As if, after blogging about why transcript integrity is literally one of the reasons TextSecure doesn't use mpOTR, they were unaware of the importance of the feature.
mpOTR is a dead end. It's unfortunate you invested in it, but that is what it is.
I agree that mpOTR is a dead end. The initial paper by Goldberg et al describes a protocol that is bulky and largely undefined. I should mention that for those reasons, Cryptocat's group chat effort has been relabelled to "mpCat" instead of "mpOTR" — we're moving on to creating a protocol suitable for synchronous use-cases specifically (since TextSecure already has the asynchronous use-case figured out) without shouldering the bulkiness and obsolete nature delineated in mpOTR's original description. One of the things that is actually addressed better is transcript consistency: in mpCat, it will function on a level of reliability that is in fact continuous and not just occurs once per entire conversation.
We recently concluded mpCat's first review summit, and were very lucky to have the feedback of experts such as Trevor Perrin, Joseph Bonneau and Ximin Luo. We also invited members from TextSecure's team in order to help us understand the use-cases scenarios they have experience in. For what it's worth, the TextSecure members that were invited were seen as open source peers, and not as "competitors" as you put it. I should mention that TextSecure's research frequently came up while working on mpCat, and that they are contributing more to this field than most other projects. That's why I say they are inspiring.
An uninformed reader of your root comment on this thread would be surprised by that concession. Is my conclusion incorrect, or was your original comment deceptive? (Unintentionally, I'm sure.)
Just as a note, I'm sincerely discouraged from attempting to have an informative discussion with you by the fact that you keep assuming bad faith on my part, and generally responding in a needlessly rude and aggressive fashion. Consider that your general approach in this particular discussion might be why information security has a bad name as a poisonous field. If I don't reply to parts of your post, consider that it is because they are phrased in a way that assumes and implies a complete understanding, wrapped in aggression and the assumption of bad faith. I'm not here for that kind of discussion.
People can decide for themselves whether you meant to "point out a current problem in the protocol design" (a confusing question, given that your objection is about UI). You know what I think already.
This is apparently so much the case that Nadim has acknowledged jettisoning his existing protocol to come up with a new protocol that will support it.
You could disagree with me, but I don't think you can do so without acknowledging that the comment that introduced this issue to the thread was... let's say "not fully informative".
Also, the reason for us moving to a new protocol has more to do with formal security proofs than being able to adopt new properties.
Some context: http://tobtu.com/decryptocat.php
(Yes, we know you addressed these issues; the page I just linked to says that).
* You complained about TextSecure's "lack" of transcript integrity.
* I pointed out that transcript integrity was a prominent feature of the blog post we're talking about, and a feature that the actual TextSecure protocol does vastly better than mpOTR.
* Someone else objected to allusions to TextSecure's transcript consistency feature as vaporware, given that Cryptocat actually has a UI for this.
* I pointed out that the protocol Cryptocat builds that UI on is so bad that you conceded downthread that you're building a new protocol --- you made that concession in direct response to my point about mpOTR's inferior transcript consistency.
* Your response is to imply that improved transcript consistency is not a significant reason for abandoning your existing protocol.
* I point out the inconsistency.
* You object that I'm not "adding anything to the conversation".
> I pointed out that the protocol Cryptocat builds that UI on is so bad that you conceded downthread that you're building a new protocol --- you made that concession in direct response to my point about mpOTR's inferior transcript consistency.
This is the problem. You're assuming that my mention of mpCat was a concession made in "direct response" to your point about mpOTR, whereas it's actually brought up as a tangent. The reason we're building a new protocol is to be able to subject it to formal security proofs, as mentioned prior. It doesn't have to do with the existing protocol being "bad" or not or its current integration into the UI.
Regarding my other implied statements, I think it would be better to stick to claims I am explicitly making instead of assuming implications on my part. That being said, I apologize and will try to be more clear in my future comments in order to avoid assumptions.
I'm also not sure why you keep bringing up mpOTR. As I mentioned in my other post that you refer to, we're not using it anywhere nor do we plan to. We're building a modified version which is far less bulky, etc.
Are you sure this is correct? From the blog post, it seems like this is impossible:
https://whispersystems.org/blog/images/groups-pairwise-optim...
However, there’s an optimization we can make for longer messages and media. The sending client generates an ephemeral symmetric key K, encrypts the message with K (C = EK(P)), and then transmits a single copy of the ciphertext (C) along with the pairwise encryptions of the plaintext hash and the small key K:
So, when a client wants to send a message to the group (like "How are you?") under this scheme, the client encrypts the message using a random encryption key K, yielding message ciphertext C. The client transmits to the server, then the server sends C to every other member of the group.
Since C can only be decrypted by someone who knows K, our client must of course send K to every other member of the group. This is easily accomplished: the client encrypts K once per other member. So, if there are N members in the group, this yields N-1 small ciphertexts. Let's call them "key ciphertexts". These "key ciphertexts" are sent to the server and routed to the appropriate recipient, who decrypts it, thus receiving K. Then the recipient decrypts C using K, yielding the client's original message ("How are you?").
So even though the client is indeed generating a ciphertext per recipient, that ciphertext contains nothing but the decryption key K. It doesn't contain the client's actual message. The actual message is contained in ciphertext C, which is generated by the client and sent to the server only once, and C is relayed verbatim to every other member. That's why I say your attack seems impossible: every member has the same message ciphertext, C, so there's no opportunity for a malicious client to send different message ciphertexts to different clients.)
As long as TextSecure uses this implementation of group messaging, then your attack shouldn't be possible, right?
As far as I know, it isn't possible for an attacker to generate a message ciphertext C such that two different decryption keys would both decrypt to valid plaintexts. There can only be one valid decryption key; trying to decrypt C using any other key would yield random output, wouldn't it?
https://news.ycombinator.com/item?id=7701510
Does your transcript consistency rely on the security of your server?
Zed Shaw was right: http://zedshaw.com/essays/thomas_ptacek_should_apologize.htm...
I agreed so much so that when I was invited to speak at CUSEC shortly thereafter, I was videotaped on stage opening my talk apologizing to him.
Zed didn't update his post on his site to account for that, although he was aware both of my plan to apologize (we spoke on the phone and I agreed the apology was warranted, though not without some debate), and of the fact that I apologized (I confirmed it for him afterwards). But Zed doesn't owe me an update to his page, and I didn't ask for one. You, on the other hand, do bear an obligation to know what you're talking about before you try to use this incident in a public discussion. You obviously haven't lived up to that obligation.
I owe you no apology. My opinion about you isn't concealed and you aren't misunderstanding me. However, you are misrepresenting my comments by referring to them as "abusive" and threatening. Unless you're threatened by criticism of your rhetoric and of the technical quality of your project.
You've ignored all my attempts to make discussion with you constructive. You are nothing but a great big bully and you should feel shame for your behaviour.
Every time I comment about anything on HN, and every time I am personally mentioned or my work is mentioned, you dutifully pop up to do your work. It's disgusting. You have a problem with me and anyone who cares to look into this can deduce the same.
I am not threatened by technical criticism, but you simply go so above and beyond reasonable discourse thanks to your irrational, mentally unfounded conviction that everything I ever do or write is necessarily either the result of incompetence or bad faith. Between me and you, it seems you never find the room for nuance and human respect!
That's my final say regarding you. Your technical knowledge is amazing and I've learned a lot from you. But you make HN a terrible place with your personality.
* Requesting the crypto challenges and receiving some of them.
* Repeatedly asking me to talk to you privately, which, as you've acknowledged here in the least charitable way possible, I refuse to do. I respond to these requests simply and directly, without insult or explanation.
That's the extent of our correspondence.
As any reader of this thread can see, you and your work weren't "mentioned" on this thread. You're the manager of a project that competes with Whisper, and you chimed in on a thread about Whisper to ding them for something. I believed that ding was unfair and explained why. You then proceeded to --- if I may be permitted an uncharitable interpretation myself --- freak the hell out.
You should have just conceded the point (it turned out later in the thread that you were wrong to have brought it up). Instead, you relentlessly personalized it. Now you're unhappy with how that went for you. Maybe this can be a learning experience.
I was fine with the meta tangent we went off on earlier today, even though it didn't have that much to do with Whisper, because it did have something to do with forward secrecy, transcript consistency, and the relationship between protocols and their implementations. This, however has nothing to do with anything. The thread shows how this meta-tangent started: with me asking a technical question about your offering, and you giving a little speech about how bad a person I am.
We should probably wrap this up now.
My initial issue remains valid, and anyone who reads through the thread can see that you repeatedly attempted to change the focus to personalize this issue towards me. It's like I'm not allowed to offer any feedback, no matter how polite, constructive or valid, while you're around. Your doublethink is egregious.
I will also say that whoever has been down-voting all of Nadim's votes (and it seems there's multiple people) ought to be ashamed of themselves. This is ridiculous.
Isn't this trivially possible in Cryptocat for anyone who controls the server?
Note: I don't mean to disparage TextSecure by saying this. By all means, TextSecure is a kickass app and you should use it. I'm just trying to point out something that could be fixed in a future update.
Yes this is a known bug since August 2013. When I found it and reported it. This was "patched" but if Mallory controls the server it is still possible. There were three ways to do this: block (which just doesn't send messages to blocked users), silent drop when invalid MAC, and silent drop when invalid tag. Block was turned into ignore and these three cases now display a warning message stating something about integrity.
I seem to not be able to find me or anyone stating that "if Mallory controls the server it is still possible". So I guess it was only said in person. Technically it's known but not publicly known :).
P.S. This was a "clamp the artery until the mpOTR protocol is finished".