On Thu, Feb 26, 2015 at 11:55 PM, Daniel Kahn Gillmor <[email protected] > 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 >
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
