[kaeporan]

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.

[tptacek]

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.

[infinity0]

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.

[tptacek]

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.

[kaeporan]

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.

[tptacek]

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.

[kaeporan]

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.

[tptacek]

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:

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.

[kaeporan]

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.

[sillysaurus3]

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:

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?

[kaeporan]

The attacker could send different Ks to each user so that K decrypts C to a different plaintext.

[sillysaurus3]

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?

[kaeporan]

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.)

[tptacek]

Hence the continuous transcript consistency feature of the TextSecure protocol. Meanwhile: I'm curious about your answer to the question 'sdevlin posted downthread:

https://news.ycombinator.com/item?id=7701510

Does your transcript consistency rely on the security of your server?

[kaeporan]

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.

Zed Shaw was right: http://zedshaw.com/essays/thomas_ptacek_should_apologize.htm...

[sigil]

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.

[kaeporan]

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.

[sdevlin]

> 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?

[sc00bz]

> 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".

[kaeporan]

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.

[sdevlin]

It seems pretty trivial to me. Can't you just send different messages to different people?

[kaeporan]

I need to investigate this properly before I offer you an educated answer with details.

[tptacek]

Any progress on this, or is 'sdevlin simply correct?