[messaging] Peerio

[Daniel Kahn Gillmor]

On Thu 2015-02-26 14:09:14 -0500, Trevor Perrin wrote:
> 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.

I agree that this part of the peerio/minilock approach is pretty
disconcerting, and not just because it goes against years of practice
and convention.  it opens an obvious hole (offline dictionary attacks
for high-value key material) and i'd love to see some more analysis of
the underlying tradeoffs involved.

> 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

There's a third possible goal that is worth enumerating here, which i'll
call the "internet café" case, since that's a shorter title than "i'd
like to be able to use any machine happens to be in front of me at any
time".

I consider the "internet café" goal itself rather suspect.  In
particular, it is risky in terms of encouraging the use of compromised
or untrustworthy hardware or software, with the usual key/passphrase
leakage risks that go along with that approach.

But the scenario in question is well-served by this private-key model,
in ways that i don't think any of Trevor's other proposed approaches can
compete with.

Nadim: are you trying to target the "internet café" case with these
designs?  If so, how do you expect users to assess or mitigate the risk
of key/passphrase leakage to compromised hardware or software,
particularly given that the key *is* the passphrase in this scheme?

      --dkg