[messaging] Peerio

[Trevor Perrin]

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

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.

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