5 ms·

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 h

tptacek 12y ago
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 12y ago
  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 12y ago
    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/forever/0/author%3Akaeporan%20textsecure 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 12y ago
      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.
      - tptacek 12y ago
        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.
        kaeporan 12y ago
        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.
sillysaurus3 12y ago
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-optimize.png 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 12y ago
  The attacker could send different Ks to each user so that K decrypts C to a different plaintext.
  - 12y ago

tptacek 12y ago

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 12y ago
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 12y ago
  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/forever/0/author%3Akaeporan%20textsecure 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 12y ago
    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.
    - tptacek 12y ago
      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.
      - kaeporan 12y ago
        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.

sillysaurus3 12y ago

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-optimize.png 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 12y ago
The attacker could send different Ks to each user so that K decrypts C to a different plaintext.
- 12y ago