[messaging] Passphrase-based key mobility (was: Peerio)

[Nadim Kobeissi]

On Mon, Mar 2, 2015 at 9:42 AM, Trevor Perrin <trevp at trevp.net> wrote:

> On Sun, Mar 1, 2015 at 10:21 AM, Nadim Kobeissi <nadim at nadim.computer>
> wrote:
> > On Sun, Mar 1, 2015 at 5:50 PM, Trevor Perrin <trevp at trevp.net> wrote:
> >>
> >> So my claims are:
> >>  a) If you want passphrase-based mobility between devices, in a
> >> protocol where the user has a home server, just storing the
> >> passphrase-encrypted private key on the home server is the best
> >> approach.
> >
> > Yup, I've already said this isn't a bad idea, and I think by this point
> it
> > seems to be the most reasonable way to move forward.
>
> I'm not recommending this - just saying it's the best version of this
> idea, so should be the basis for discussion.
>
> If you want to do this, my advice is the same as Joe's: use
> machine-generated phrases with high entropy, not user-chosen.  I don't
> know if that has the useability you want, but it would be secure.
>

I was going to wait until tonight to post this, since I'm working on
implementing it right now:

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.)

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.

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.


>
>
> >>  b) It's unclear in what use cases this is a good idea
> [...]
> >
> > This becomes a substantially more subjective discussion on
> > user-friendliness, subjective to the degree where I'm not sure it can
> lead
> > to a fruitful discussion here.
>
> Well, the first step is to determine what use cases this is addressing
> and what the alternatives are.
>
> If I want to provision a new device and have an old device at hand,
> there are good ways to copy a private key from old to new.  For
> example, use QR codes or short-auth strings [1,2] to create a secure
> channel over which to send the key.  I think scanning a QR code or
> verifying that two devices are displaying the same short string has
> good useability - probably better than a long passphrase.
>
> So that leaves cases where I want to use a new device *without* an old
> device present.  For example:
>  (a) recovering from a lost device
>  (b) using internet cafes if you don't own a device (or flash drive)
>  (c) using a friend's computer if you're away from your device
>
> For (a), users could be given the option of a recovery key, which they
> could print and store.  That's basically the same as a
> machine-generated passphrase, except users aren't expected to remember
> it or use it frequently, so there's less concern about useability.
>
> I also like the idea of users electing some M-of-N set of other users
> whom they trust, and having shares of the recovery key encrypted to
> their public keys.  We discussed ideas like this last year, though the
> context was a forgotten password rather than lost device [3,4,5].
>
> I'm not sure (b) and (c) should be supported in end-to-end secure
> software.  It seems dangerous to give users the impression of
> end-to-end security with devices they don't control.
>
> I suppose the recovery key mechanism could be used for this if some
> user really wants to, but I'm not sure (b) or (c) need more support
> than that.  And since users nowadays own smartphones that are always
> with them, this doesn't seem that important.
>
> Trevor
>
> [1] https://moderncrypto.org/mail-archive/messaging/2014/000036.html
> [2] https://moderncrypto.org/mail-archive/messaging/2014/000095.html
> [3] https://moderncrypto.org/mail-archive/messaging/2014/000362.html
> [4] https://moderncrypto.org/mail-archive/messaging/2014/000365.html
> [5] https://moderncrypto.org/mail-archive/messaging/2014/000366.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150302/01dd3d41/attachment.html>