[messaging] Peerio

[Nadim Kobeissi]

On Thu, Feb 26, 2015 at 11:55 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net
> wrote:

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

My understanding is that any search would be currently simply too expensive.


>
> > 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?
>

Clearly, I'm not targeting any use-case that includes a compromised
Internet café computer as part of the use-case. That's pretty obvious.

I think a better likening would be to how folks are able to sign into
PayPal.


>
>       --dkg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150227/575bdd58/attachment.html>