<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 2, 2015 at 9:42 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Mar 1, 2015 at 10:21 AM, Nadim Kobeissi <nadim@nadim.computer> wrote:<br>
> On Sun, Mar 1, 2015 at 5:50 PM, Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br>
>><br>
</span><span class="">>> So my claims are:<br>
>>  a) If you want passphrase-based mobility between devices, in a<br>
>> protocol where the user has a home server, just storing the<br>
>> passphrase-encrypted private key on the home server is the best<br>
>> approach.<br>
><br>
> Yup, I've already said this isn't a bad idea, and I think by this point it<br>
> seems to be the most reasonable way to move forward.<br>
<br>
</span>I'm not recommending this - just saying it's the best version of this<br>
idea, so should be the basis for discussion.<br>
<br>
If you want to do this, my advice is the same as Joe's: use<br>
machine-generated phrases with high entropy, not user-chosen.  I don't<br>
know if that has the useability you want, but it would be secure.<br></blockquote><div><br></div><div>I was going to wait until tonight to post this, since I'm working on implementing it right now:</div><div><br></div><div>We have decided to forego with user-chosen passphrases entirely, and to stick uniquely to the miniLock model of having a CSPRNG pick a high-entropy (112-bit) passphrase for users. Users will be able to set a local PIN for quick login, and can enter this passphrase once on every new device before setting a PIN (PINs are not like ATM PINs -- they're actually enforced to be strong passwords in their own right.)</div><div><br></div><div>The reason for this decision is that it addresses the root of the issue better than any other suggestion. Trevor and Michael Hamburg's suggestions are neat, but they do not improve the situation as fully as this fix would.</div><div><br></div><div>So right now, the #1 priority is remove user-set passphrases on signup and have Peerio generate you one like original miniLock does. Once that's pushed, we'll work on improving key storage and delivery.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
<br>
>>  b) It's unclear in what use cases this is a good idea<br>
</span>[...]<br>
<span class="">><br>
> This becomes a substantially more subjective discussion on<br>
> user-friendliness, subjective to the degree where I'm not sure it can lead<br>
> to a fruitful discussion here.<br>
<br>
</span>Well, the first step is to determine what use cases this is addressing<br>
and what the alternatives are.<br>
<br>
If I want to provision a new device and have an old device at hand,<br>
there are good ways to copy a private key from old to new.  For<br>
example, use QR codes or short-auth strings [1,2] to create a secure<br>
channel over which to send the key.  I think scanning a QR code or<br>
verifying that two devices are displaying the same short string has<br>
good useability - probably better than a long passphrase.<br>
<br>
So that leaves cases where I want to use a new device *without* an old<br>
device present.  For example:<br>
 (a) recovering from a lost device<br>
 (b) using internet cafes if you don't own a device (or flash drive)<br>
 (c) using a friend's computer if you're away from your device<br>
<br>
For (a), users could be given the option of a recovery key, which they<br>
could print and store.  That's basically the same as a<br>
machine-generated passphrase, except users aren't expected to remember<br>
it or use it frequently, so there's less concern about useability.<br>
<br>
I also like the idea of users electing some M-of-N set of other users<br>
whom they trust, and having shares of the recovery key encrypted to<br>
their public keys.  We discussed ideas like this last year, though the<br>
context was a forgotten password rather than lost device [3,4,5].<br>
<br>
I'm not sure (b) and (c) should be supported in end-to-end secure<br>
software.  It seems dangerous to give users the impression of<br>
end-to-end security with devices they don't control.<br>
<br>
I suppose the recovery key mechanism could be used for this if some<br>
user really wants to, but I'm not sure (b) or (c) need more support<br>
than that.  And since users nowadays own smartphones that are always<br>
with them, this doesn't seem that important.<br>
<br>
Trevor<br>
<br>
[1] <a href="https://moderncrypto.org/mail-archive/messaging/2014/000036.html" target="_blank">https://moderncrypto.org/mail-archive/messaging/2014/000036.html</a><br>
[2] <a href="https://moderncrypto.org/mail-archive/messaging/2014/000095.html" target="_blank">https://moderncrypto.org/mail-archive/messaging/2014/000095.html</a><br>
[3] <a href="https://moderncrypto.org/mail-archive/messaging/2014/000362.html" target="_blank">https://moderncrypto.org/mail-archive/messaging/2014/000362.html</a><br>
[4] <a href="https://moderncrypto.org/mail-archive/messaging/2014/000365.html" target="_blank">https://moderncrypto.org/mail-archive/messaging/2014/000365.html</a><br>
[5] <a href="https://moderncrypto.org/mail-archive/messaging/2014/000366.html" target="_blank">https://moderncrypto.org/mail-archive/messaging/2014/000366.html</a><br>
</blockquote></div><br></div></div>