[messaging] Peerio

[Nadim Kobeissi]

On Thu, Feb 26, 2015 at 8:09 PM, Trevor Perrin <trevp at trevp.net> wrote:

> On Wed, Feb 25, 2015 at 3:06 PM, Nadim Kobeissi <nadim at nadim.computer>
> wrote:
> >
> > I was inspired by the recent debate over PGP to write this blog post:
> > http://blog.peerio.com/post/112078157509/going-beyond-pgp
>
> I'd be interested to hear more about peerio's approach to passwords
> and private keys.
>
> The current design seems to be:
>  (a) user chooses a passphrase which generates their private key
>  (b) user also chooses a shorter "PIN" which can be used to login
>

That's correct. Passphrases are derived using salted scrypt (which is
"memory hard"). PINs are optional.


>
> Of course, (a) means anyone the user communicates with can attempt
> offline guessing of the passphrase.  The system tries to reject
> poorly-chosen passphrases, but there's no guarantee of success.  For
> example, "BrightStarWouldIWereSteadfastAsThouArt" is accepted but I'm
> a known sonnet fan, so that's not secure for me.
>
> So a risk is being taken here, compared to the more usual approach of
> generating private keys randomly.  The underlying crypto that peerio
> uses (miniLock) doesn't care how private keys are generated, so this
> decision seems orthogonal to the rest of the system, and I'm not sure
> what it's benefits are.
>


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.

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.


>
> If the goal is improving useability in the multidevice case there are
> ways to have your existing and new devices do a "device pairing"
> protocol via PAKE, or short-auth strings, or scanning a QR code.  The
> pairing would establish encrypted communications between devices
> through which the private key could be sent.  It's not obvious the
> peerio UX of entering a long passphrase into each of your devices is
> an improvement.
>
> If the goal is useability in the lost-device, private-key recovery
> case, then there also alternatives, such as:
>  - storing a password-encrypted private key only on the user's server,
> so users are only exposed to password-cracking attacks from their
> server, not from every correspondent.
>  - giving users the option to print out or save a base64'd copy of the
> private key, so they can make a backup without exposing them to
> password-cracking at all
>  - giving users the option to *not* make such a backup, which is
> arguably the most secure (and simplest) of options
>
> Anyways, this is an interesting approach to private-key handling, but
> I'm not yet convinced that its costs and benefits stack up well
> compared to alternatives (and I also think peerio and miniLock don't
> require this, and would work fine if private keys were generated
> randomly).
>
> Trevor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150226/984e27f7/attachment.html>