<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 26, 2015 at 8:09 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Wed, Feb 25, 2015 at 3:06 PM, Nadim Kobeissi <nadim@nadim.computer> wrote:<br>
><br>
</span><span class="">> I was inspired by the recent debate over PGP to write this blog post:<br>
> <a href="http://blog.peerio.com/post/112078157509/going-beyond-pgp" target="_blank">http://blog.peerio.com/post/112078157509/going-beyond-pgp</a><br>
<br>
</span>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></blockquote><div><br></div><div>That's correct. Passphrases are derived using salted scrypt (which is "memory hard"). PINs are optional.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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>
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></blockquote><div><br></div><div><br></div><div>I think storing the private key in the user's brain, in the form of a passphrase, is more secure than having it lying around on every computer they use for crypto in the form of a PGP key file. Deriving private keys from a strong passphrase offers an ephemeral portability, where I can carry my key identity with me in my head, use it on any computer, without permanently any private key information on said computer (that is, unlike PGP.) When I'm using a trusted friend's computer, or when I buy a new one, I can be all set just by entering my passphrase and logging in like I'd log into Gmail or Facebook. I think this is very important for people to be able to do.</div><div><br></div><div>I believe that there are risks with any private key management strategy, and that in this case they're jumping out more because of the exotic way miniLock deals with key generation. Sure, users can pick a weak passphrase, but this is offset with a somewhat good passphrase strength checker, coupled with somewhat overkill scrypt parameters, which would make any keyspace search, including dictionary-based ones, very computationally expensive, to say the least. Ultimately, I can't reasonably stop users completely from picking a bad passphrase, same as I can't stop them from sending me their passphrase via plaintext email asking for support (this has happened once so far). User education matters here. and so do safeguards. With those in place, I think accomplishing this kind of portability, without having to store private keys anywhere at any time, is quite valuable.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<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>
Anyways, this is an interesting approach to private-key handling, but<br>
I'm not yet convinced that its costs and benefits stack up well<br>
compared to alternatives (and I also think peerio and miniLock don't<br>
require this, and would work fine if private keys were generated<br>
randomly).<br>
<span class=""><font color="#888888"><br>
Trevor<br>
</font></span></blockquote></div><br></div></div>