Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Feb 27 07:26:55 PST 2015
On Fri 2015-02-27 04:50:19 -0500, Nadim Kobeissi wrote:
> On Thu, Feb 26, 2015 at 11:55 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
>> 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.
I'm glad to hear that. Do you have pointers to details of your
analysis? I'd love to read those thoughts.
> 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 agree that it's obvious to the people on this list. Is it obvious to
the users of peerio?
> I think a better likening would be to how folks are able to sign into
Do you know how many people sign into PayPal from internet cafés?
Internet café management software exists that specifically hooks into
PayPal so customers can "pay for use directly from the client computer"
, so this is not a negligible use case in the real world, as terrible
as it seems to all of us.
I think the messaging around this sort of better usability (and it is
better usability, which is very cool, Nadim) needs to be pretty careful
to avoid steering users into environments where it's unsafe -- there is
no second chance (i.e. no changing the password on the stored key) once
the password/key becomes compromised.
Systems where the key is stored on a device and must be managed provide
an implicit "guard rail" against use on compromised machines, because
the user must think about key transfer in addition to knowing the
password. This system doesn't have that guard rail.
More information about the Messaging