I'm a big fan of TextSecure and recommended it to all my friends, both those in IT and 'normal' people. Usually, I managed to convince them that the open source nature of TextSecure and the crypto experts behind it (e.g. Moxie) make it more secure than Threema/... . However, the more sceptical ones among my friends always asked two questions, which I didn't have a good answer for:
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].
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.
> 1. What is TextSecure's business model? Who pays for the server infrastructure?
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.
Hey moxie, I recently myself switched to using TextSecure (mostly was just looking from an SMS app from reputable people, but the crypto parts are a nice bonus). The above question about the business model was also my first question after my initial evaluation. It would be awesome if you could put this info somewhere on the website (maybe I missed it?).
That is indeed confusing. Because the names are so similar, there is an implied close relationship between these two entities. Have you considered renaming the project?
An iOS version is in progress and should be released in the next few months [1].
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.
I'd actually like a Chrome browser extension version, too (yes, I recognize the vulnerabilities vs. a true native client, but signed browser extensions mitigate a lot of those)
What's the relation between the server and the SMS verification when setting up the app? I haven't tried TextSecure in a while, but when I tried right after you announced TextSecure v2, I kept getting failure to send me the SMS, and I had to receive the robo-call. I had a friend from another country who experienced the same. Is that still a problem?
There were some capacity issues when the new version of TextSecure was first released. The SMS code is used to verify ownership of a number before it can be used for Push messaging.
Note that you're forking the net with this though.
As far as I understood in the posts about TextSecure here:
- 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'd like a good answer to the first question as well (it would be ideal if there was an easy way we could host it ourselves), at least OpenWhisperSystems does not belong to Twitter [0]:
> 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.
Afaik TextSecures server infrastructure consists mainly of Google Play Services which comes at no financial costs for them but with the downside of depending on Google to temporary store encrypted text.
This isn't entirely true. A detailed explanation is available in the Open WhisperSystems Support Center [1] and several solutions are in the works. Google's GCM push messaging framework is used only for message delivery; the TextSecure server itself is open source [2].
It's true currently. At the support page you link first it is promised that it will be eventually changed but now: "Outside of Google's GCM, the fact is that there are no alternative push messaging frameworks for Android that can scale to the millions of users that TextSecure has. GCM requires Google Play."
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.
Full disclosure: I wrote that Support Center article. The comment I was replying to made it sound as though TextSecure's infrastructure is almost entirely Google-based. It is not, and that's what I meant when I said "This isn't entirely true." The server is open source and it already includes preliminary support for WebSockets and Apple's APN push messaging network. Google's GCM is merely one component, and alternatives are being worked on.
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.
So it's still true that currently the sever side uses only Google servers. It's nice to hear that there's work on the alternatives.
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.
The server side is currently relaying messages for the in-progress iOS and Chromium clients. That's functionality that exists today, even though the clients are still under development. The TextSecure server is an elegant and important part of TextSecure's infrastructure. I stand by my assertion that it's an oversimplification to say that TextSecure == Google's Servers.
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.
Yeah. The more substantial downside is that Google effectively has remote root access to every device which holds decryption keys for that text. That's not exactly ideal.
I would rather pay a nominal fee to support their infrastructure than have to rely on Google Play Services for a supposedly "secure" messaging service.
I see you point but it should not weaken the security because encryption happens at the client, Google "only" gets metadata which at least authorities will get anyway.
Besides, TextSecure is free software so it might possible to run your own server at least in the future.
Every network that carries your communication gets the metadata.
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.
I don't know, but I would have guessed that Google needs to know when it should deliver a message and where it should go, no? That is metadata in my definition.
GCM payloads are fully encrypted. Google would be able to tell that you are a TextSecure user who is receiving a message, but they cannot tell who the message is coming from nor can they look at its contents (obviously).
There may not be the traditional byte at a time comparison type timing attack, but maybe this is still vulnerable to timing correlation attacks in the same sense that tor is. That is, Google or someone monitoring Google's network can look at all the messages and see who is talking to whom by matching up timing and encrypted message bodies.
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.
Reference [1] doesn't describe what TextSecure actually does.
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.
Yes my reading of the blog led me to believe they use the naive solution because it only lists solutions which don't work and concludes that TextSecure is too big to use these.
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.
> Do you mean that TextSecure may send encrypted messages to contacts who don't have it?
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?
Thanks for replying. My bullet (2) was stupid. Hopefully bullet (1) makes sense.
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.
You're suggesting that the client submits a hash of the combination of the address (phone number) and something only a legitimate sender would know that has sufficient entropy to act as an effective salt value.
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.
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.
> restoring the SMS database after purchasing a new device is not impossible.
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!
" ephemeral signing key pair along with K. ... hash-ratcheting K and including a signature in the transmitted ciphertext."
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)?
On somewhat of a meta-HN note it seems strange to me that every one of kaeporan's comments has been heavily downvoted. Seems unnecessary - maybe the downvote karma threshold needs to be raised again? To 1000?
I wished moxie would have discussed more the group management aspects.
> 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)?
TextSecure groups are fully egalitarian. Anyone may add members and no one may force an existing member to leave. There are no privileged members.
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.
The fact that transcript consistency is waved aside, despite being an essential property of a messaging protocol especially in a group context, is problematic, from my perspective.
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.
This post says that TextSecure implements transcript consistency in the protocol, and in a fashion objectively superior to that of mpOTR: the TextSecure protocol can provide continuous consistency checks, while mpOTR can do so only when the session is torn down. What the TextSecure client does not yet do is provide a UI for that feature of the protocol.
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.
The post only says that TextSecure have begun implementing this. The hash-parent-pointers is a good start and enables more functionality in this direction, but it doesn't mention other strategies that actually ensure the user's confidence in consistency. For example, checking for others' acknowledgements, heartbeats, or resending a potentially-inconsistent situation. None of this is that hard, but the post is missing important chunks, yet you are waving this over.
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.
The thread you're commenting at the top of litigates the point you're making in detail. There's nothing I can say to your comment that I haven't said already.
I'm quite certain that the current TextSecure chat allows my proposed scenario with Alice, Bob and Carol to go through without issue. This is the main problem here. So while transcript consistency is discussed in the blog post, it remains the case that Alice can send a different message to Bob and Carol without being detected.
This is a comment you could have written without even reading my comment. You haven't responded to anything I just wrote. I'm not surprised; your function in TextSecure threads seems to be to pop out and complain about TextSecure without mentioning that you're the author of Cryptocat, a competing (and inferior) offering.
I think TextSecure is an excellent and inspiring project. All I'm trying to do is identify an area of concern for me. I'm not sure why you're attacking me personally here. I think my initial point of concern stands and I hope the TextSecure developers will work on addressing it.
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.
I'm not attacking you personally. I object to the fact that you didn't lead with the fact that you compete with TextSecure. As for your tone regarding the TextSecure project, here are all your messages regarding TextSecure:
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.
I'm sorry, but I don't think your approach to this discussion is constructive. I hope TextSecure developers address my initial concern, and that's all for me.
mpOTR sacrifices forward secrecy and provides transcript consistency with limited semantics, which has the side effect of making the "transcript integrity feature" trivial to implement, because the protocol supports only a silly version of it. mpOTR clients can't simply fix this with UI, because these are properties of the protocol.
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.
It doesn't matter what kind of transport integrity the underlying protocol has if that integrity information isn't actually used. What's more, it's not just that they haven't got around to implementing UI for it, the problem is they can't figure out how to meaningfully expose that information in the UI - which, with consistency semantics this complicated, is actually the hardest part of the problem! They don't even really have the outline of a solution, let alone the transcript integrity you're claiming they have. Yet here you are treating their vapourware as though it provides more protection than something that actually exists.
The UI for transcript consistency is absolutely not the hardest part of the problem. We are comparing an existing UI on top of a broken transcript consistency feature to a nonexistent UI on a functional, extant transcript consistency protocol. I am objecting to the notion that an extant UI built on a mound of sand somehow trumps a concrete foundation poured for a better UI.
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".
UI is absolutely a very difficult part of the problem, and here we see an example outlining this. Even a capable protocol still has problems if the UI fails to translate the capabilities into benefits and security increases for users. I speak from experience: Cryptocat has had some serious issues that were due simply to incomplete UI, the most recent of which was related to authentication.
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.
It really seems like you wrote this comment not to add anything to the conversation, but simply to discourage me from commenting. I really don't understand. I'm trying to be constructive here and I wish you'd join me. Your comment right now just flails around for abrasive things to put together into a statement that is completely incoherent and off-topic.
Your inability to respond to my actual comments appears almost willful. Let's break this down:
* 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".
Thanks for laying out your thought process, it's very helpful.
> 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.
Maybe some other reader can tell me whether Nadim is saying that he endorses TextSecure's continuous transcript consistency model and is working on folding it into his new protocol, or whether he thinks the mpOTR model of consistency checking only at the conclusion of sessions is so useful that not providing it is worth dinging TextSecure over, or whether there's some third option I'm excluding. Because I can't even figure out what Nadim is trying to say anymore.
I endorse continuous transcript consistency, but believe that TextSecure currently does not allow its users to benefit from it and that this should be resolved. I think mpOTR is irrelevant to this discussion. I hope that's clear!
Thanks for agreeing to turn the discussion in a more constructive direction, Thomas.
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.
Despite the fact that you've fleshed your responses out from single sentences to whole paragraphs, there is still no technical content in this comment that addresses my comment. It appears that your response is "no, we don't properly do transcript consistency either, but we're working on it". But I had to read between the lines of your name-dropping comment to come to that conclusion.
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.)
My original comment was simply to point out a current problem in this protocol design. There are some ways one can deploy to make it more difficult for Alice to send different messages to Bob and Carol without being detected, and they are deployed in Cryptocat (you're welcome to peruse the codebase and documentation.)
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.
Your original comment is right there for readers to see, as is Moxie's post, which covers the issue in depth.
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.
That is incredibly annoying, because it will probably have the effect of setting off the ring detector and burying the story, which is too bad, because the TextSecure post we're talking about here is excellent. I'll let the mods know. Thanks for catching this.
I'm quite certain that the current TextSecure chat allows my proposed scenario with Alice, Bob and Carol to go through without issue. This is the main problem here. So while transcript consistency is discussed in the blog post, it remains the case that Alice can send a different message to Bob and Carol without being detected.
Are you sure this is correct? From the blog post, it seems like this is impossible:
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?
If you try to decrypt C with any key other than the K that was used to encrypt it, you'll get gibberish (the decryption process will fail).
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?
I hope I'm not mistaken, but my understanding is that you can have the same message C that would decrypt with K1 to the plaintext "Hello world" but with K2 to another plaintext of your choice ("Jello Warld" or whatever.)
This is only true for one-time-pad encryption. For a given AES-256 cipher mode and ciphertext C, there are at most 2 * * 256 possible decryptions of C. For most pairs of ciphertext and plaintext (C, M2) longer than 32 bytes, there doesn't exist a key K2 that decrypts C to M2. Even if K2 exists, finding K2 given (C, M2) with an average work factor less than 2 255 implies you've found a weakness in AES-256.
Hence the continuous transcript consistency feature of the TextSecure protocol. Meanwhile: I'm curious about your answer to the question 'sdevlin posted downthread:
Sorry, Thomas, but after you repeatedly replied to my private requests for conflict resolution with threats and abusive remarks, I refuse to interact with you entirely, publicly or privately. Those curious as to why I'm saying this should read Ptacek's other comments on this thread for a primer.
That's funny. I agree that Zed Shaw was right: I thought that the context of the barb I directed at him in a talk many years ago --- where I compared him with Daniel Bernstein, Theo de Raadt, and Jason Fried from 37signals --- put him in an appreciative and positive light. But he didn't think so --- I hyperbolically said "Zed Shaw will kill your company" (the same way Theo and Bernstein would), and on review, I agreed that it was crazy that I thought the slide I had with him on it would seem benign to everyone.
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.
Since you've asked me not to share contents of private emails, I won't. But your insistence on assuming bad faith on my part and rudely rejecting any conflict resolution from my end is deplorable, and you should be ashamed of how baselessly aggressive you have been towards me. You consistently spin everything I say and respond to my attempts to be constructive by encouraging groupthink against what I'm trying to say using irrational fodder.
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.
a question.
which application should I use if I have an iphone? (and do not want to change the iphone)
what program would you recommend?
thank you very much
> 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.
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.
Instead of writing your comments for Thomas, why not write them for the HN community? We're all very interested in hearing your thoughts. Thomas poses some good questions; why not consider answering them for us?
They're not waving aside transcript consistency with their protocol, near as I can tell. ("We believe that it is possible to provide transcript consistency while preserving an asynchronous orientation.")
mpOTR, on the other hand, only shows transcript consistency at the end of a group chat session. This does seem problematic.
Yes, per your quote, transcript consistency is discussed. But the discussion simply outlines problems with implementing it in their mobile use case — to my understanding the current version being offered to users doesn't have strong transcript consistency.
> 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.
Isn't this trivially possible in Cryptocat for anyone who controls the server?
> Isn't this trivially possible in Cryptocat for anyone who controls the server?
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".
I don't think it would be trivial (it's likely possible to some degree, but authentication and integrity checks might make it slightly more difficult), but the issue with this protocol is that you don't even need server control — any client with TextSecure installed can do this.
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.
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.