[messaging] How secure is TextSecure?

[Joseph Bonneau]

On Fri, Dec 19, 2014 at 5:35 PM, Trevor Perrin <trevp at trevp.net> wrote:
>
> On Fri, Dec 19, 2014 at 1:28 PM, Joseph Bonneau <jbonneau at gmail.com>
> wrote:
> >
> > I had a simple thought reading this paper: why not have the server simply
> > reject a user from ever attempting to register a key with the same
> > fingerprint as a key anybody else has already registered? That would
> block
> > UKS attacks (modulo server collaboration)
>
> If Bob lies to his girlfriend Alice and give her Charlie's fingerprint
> and phone number, Bob doesn't need to register anything.
>

I guess there are two types of attack:

In the first one Bob and Charlie both have accounts (separate usernames),
and Bob changes to have Charlie's key fingerprint then tries to redirect
Alice's message to Charlie. I was arguing you can prevent this version
fairly cheaply in a centralized service by preventing key fingerprint
collisions.

In the second, Bob has no account. He tells Alice that Charlie's username X
is really his (and perhaps even has Charlie's QR code on his screen so
Alice is convinced she's "verified" that Bob really owns X). Fixing that
probably requires the verification is a challenge-response proving
knowledge of the private keys as the authors of the paper suggested and I
agree that's probably not worth it.


> Alice will simply text "I love you" thinking it's going to Bob, but
> instead it will confuse Charlie.  I've argued this is a trust problem
> more than a technical one - if Alice trusts someone to give her Bob's
> information, she's at risk of being lied to.
>
> If Bob only lies about his fingerprint, not his phone number, then the
> server would have to collude to misroute the message to Charlie, so a
> server-side check doesn't add much value.
>
> > if two users choose the same key accidentally
> > something has probably gone horribly wrong entropy-wise and it would be
> > worthwhile to detect that.
>
> Agreed that scanning for public-key collisions has value to detect bad
> RNGs.
>

 Yes, this is vastly more important than detecting UKS attacks but that
might be a nice side-effect. If nothing else comes out of this UKS business
it would be nice to see this happen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20141219/d4a9e94b/attachment.html>