On Wed, Nov 5, 2014 at 10:46 PM, David Leon Gil <[email protected]> wrote: > On Sat, Nov 1, 2014 at 3:02 PM, Nadim Kobeissi <[email protected]> wrote: >> ------ Original Message ------ >> From: "David Leon Gil" <[email protected]> >>> >>> They present an unknown key-share attack on TextSecure; this is rather >>> serious, to say the least. >> >> I disagree that this is a serious attack. > > I agree, mostly: it's a serious protocol design mistake. But it is not > usefully exploitable, AFAIK.
I work on TextSecure, so I may be biased. But I don't think there's any protocol mistake here, much less a serious one. Moxie addressed this pretty well in [1], but I'll add to it. Here's the basic pattern of the "Unknown Key Share" issue: Bob wants to play a prank on Charlie. He tells his girlfriend Alice that he has a new phone number. But he lies and gives her Charlie's phone number instead of his own. Alice texts "I love you!" to Charlie, thinking it's Bob. --- We can add crypto, but in any system where Bob presents his contact and authentication info to Alice there's going to be this risk. This isn't just TextSecure, it's almost everything: * In PGP Bob could present Charlie's encryption key to Alice * In OTR, SSH, or TextSecure Bob could present Charlie's fingerprint * In NameCoin, PKI, or any centralized service Bob could present Charlie's username I doubt any of these matter much. I also doubt these problems can be completely solved, though there are mitigations that help in some cases. For example, TextSecure's main key verification method is for both parties to perform a mutual exchange of fingerprints via QR codes. If Alice and Charlie have not performed such an exchange, Charlie has no reason to place strong trust in Alice's message that she loves him. If Alice and Charlie *have* performed such an exchange, then Alice's GUI should inform her when she performs a key verification with a key she already knows about, so she can detect Bob's attempt to claim Charlie's key. The key verification process doesn't display this currently, and needs work in general, but this is UI/UX improvement, not protocol changes. The RUB authors propose a different mitigation, where Alice uses QR codes to send Bob a challenge during key verification, and he responds with a proof-of-possession of the private key. That adds difficulty but is still defeatable, since Alice could relay the challenge to a confederate who challenges Charlie, and then relays the response back. That also changes verification to require 3 QR codes, instead of 2. That's a significant worsening of the UX. So until we have NFC or something to make round-trips easier, we're unlikely to do complex verification protocols like that. Trevor [1] https://moderncrypto.org/mail-archive/messaging/2014/001030.html _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
