On Fri, Dec 19, 2014 at 5:35 PM, Trevor Perrin <[email protected]> wrote: > > On Fri, Dec 19, 2014 at 1:28 PM, Joseph Bonneau <[email protected]> > 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.
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
