<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 26, 2015 at 11:55 PM, Daniel Kahn Gillmor <span dir="ltr"><<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu 2015-02-26 14:09:14 -0500, Trevor Perrin wrote:<br>
> I'd be interested to hear more about peerio's approach to passwords<br>
> and private keys.<br>
><br>
> The current design seems to be:<br>
>  (a) user chooses a passphrase which generates their private key<br>
>  (b) user also chooses a shorter "PIN" which can be used to login<br>
><br>
> Of course, (a) means anyone the user communicates with can attempt<br>
> offline guessing of the passphrase.  The system tries to reject<br>
> poorly-chosen passphrases, but there's no guarantee of success.  For<br>
> example, "BrightStarWouldIWereSteadfastAsThouArt" is accepted but I'm<br>
> a known sonnet fan, so that's not secure for me.<br>
<br>
</span>I agree that this part of the peerio/minilock approach is pretty<br>
disconcerting, and not just because it goes against years of practice<br>
and convention.  it opens an obvious hole (offline dictionary attacks<br>
for high-value key material) and i'd love to see some more analysis of<br>
the underlying tradeoffs involved.<br></blockquote><div><br></div><div>My understanding is that any search would be currently simply too expensive.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> So a risk is being taken here, compared to the more usual approach of<br>
> generating private keys randomly.  The underlying crypto that peerio<br>
> uses (miniLock) doesn't care how private keys are generated, so this<br>
> decision seems orthogonal to the rest of the system, and I'm not sure<br>
> what it's benefits are.<br>
><br>
> If the goal is improving useability in the multidevice case there are<br>
> ways to have your existing and new devices do a "device pairing"<br>
> protocol via PAKE, or short-auth strings, or scanning a QR code.  The<br>
> pairing would establish encrypted communications between devices<br>
> through which the private key could be sent.  It's not obvious the<br>
> peerio UX of entering a long passphrase into each of your devices is<br>
> an improvement.<br>
><br>
> If the goal is useability in the lost-device, private-key recovery<br>
> case, then there also alternatives, such as:<br>
>  - storing a password-encrypted private key only on the user's server,<br>
> so users are only exposed to password-cracking attacks from their<br>
> server, not from every correspondent.<br>
>  - giving users the option to print out or save a base64'd copy of the<br>
> private key, so they can make a backup without exposing them to<br>
> password-cracking at all<br>
>  - giving users the option to *not* make such a backup, which is<br>
> arguably the most secure (and simplest) of options<br>
<br>
</span>There's a third possible goal that is worth enumerating here, which i'll<br>
call the "internet café" case, since that's a shorter title than "i'd<br>
like to be able to use any machine happens to be in front of me at any<br>
time".<br>
<br>
I consider the "internet café" goal itself rather suspect.  In<br>
particular, it is risky in terms of encouraging the use of compromised<br>
or untrustworthy hardware or software, with the usual key/passphrase<br>
leakage risks that go along with that approach.<br>
<br>
But the scenario in question is well-served by this private-key model,<br>
in ways that i don't think any of Trevor's other proposed approaches can<br>
compete with.<br>
<br>
Nadim: are you trying to target the "internet café" case with these<br>
designs?  If so, how do you expect users to assess or mitigate the risk<br>
of key/passphrase leakage to compromised hardware or software,<br>
particularly given that the key *is* the passphrase in this scheme?<br></blockquote><div><br></div><div>Clearly, I'm not targeting any use-case that includes a compromised Internet café computer as part of the use-case. That's pretty obvious.</div><div><br></div><div>I think a better likening would be to how folks are able to sign into PayPal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
      --dkg<br>
</font></span></blockquote></div><br></div></div>