<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 19, 2014 at 5:35 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Fri, Dec 19, 2014 at 1:28 PM, Joseph Bonneau <<a href="mailto:jbonneau@gmail.com">jbonneau@gmail.com</a>> wrote:<br>
><br>
> I had a simple thought reading this paper: why not have the server simply<br>
> reject a user from ever attempting to register a key with the same<br>
> fingerprint as a key anybody else has already registered? That would block<br>
> UKS attacks (modulo server collaboration)<br>
<br>
</span>If Bob lies to his girlfriend Alice and give her Charlie's fingerprint<br>
and phone number, Bob doesn't need to register anything.<br></blockquote><div><br></div><div>I guess there are two types of attack:</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alice will simply text "I love you" thinking it's going to Bob, but<br>
instead it will confuse Charlie.  I've argued this is a trust problem<br>
more than a technical one - if Alice trusts someone to give her Bob's<br>
information, she's at risk of being lied to.<br>
<br>
If Bob only lies about his fingerprint, not his phone number, then the<br>
server would have to collude to misroute the message to Charlie, so a<br>
server-side check doesn't add much value.<br><span class=""><br>
> if two users choose the same key accidentally<br>
> something has probably gone horribly wrong entropy-wise and it would be<br>
> worthwhile to detect that.<br>
<br>
</span>Agreed that scanning for public-key collisions has value to detect bad RNGs.<br></blockquote><div><br></div><div> 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.</div></div></div></div>