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?
