Daniel Kahn Gillmor
dkg at fifthhorseman.net
Thu Feb 26 14:55:25 PST 2015
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
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
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?
More information about the Messaging