[messaging] Are we pursuing real solutions for security?

[Christine Corbett Moran]

For side by side in person comparison, nothing beats a face for "number of
bits a human can distinguish" AFAICT. I'm sure the state of the art in
going from bits=>face is lacking, and suppose the uncanny valley might
always screw things up. (unproven hypothesis: two digital faces are more
easily intertwined than human?)

For over the phone, same probably true with an artificial voice.

I think that's fundamentally the best we can do given the constraints for
"zero click" analogue; i.e. mimic how people actually do zero click
authentication in real life. But getting there (face and voice synthesis) I
think would be very tough at this stage. So we have to deal with
approximates.

C


On Tue, Mar 11, 2014 at 10:12 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net
> wrote:

> On 03/11/2014 04:31 PM, elijah wrote:
> > On 03/11/2014 03:33 AM, Tony Arcieri wrote:
> >
> >> I don't think these solutions are providing effective security. I feel
> >> we need to start from the real needs of real users, and work backwards.
> >
> > For me, the goal needs to be zero-click encryption, as Schneier has
> > recently called it, so I get very uncomfortable with any discussion of
> > fingerprints or even SAS.
>
> we're not actually talking about encryption here, though; we're talking
> about authentication.  if we don't bother authenticating the peer,
> zero-click encryption is trivial (and we should be doing that already,
> though there are many places that we do not).
>
> do you have proposals for how to do "zero-click authentication"?  the
> key management problem is a much harder than the encryption problem.
>
> The answers seem to be a choice of one (or more) of the following evils:
>
>  0) TOFU (e.g. ssh-style) -- not protected against first use; requires
> large amounts of client-side state; no clear way to distinguish
> legitimate key transition from an attack; no global view
>
>  1) CA-style infrastructure (e.g. "X.509 PKI") -- untrustworthy parties
> put in trusted positions; horrible revocation semantics
>
>  2) public logs (e.g. Certificate Transparancy) -- expensive to run and
> audit; zone enumerability; "phoning home"; no real-world experience yet
>
>  3) certification network (e.g. OpenPGP "Web of Trust") --
> complicated/confusing user experience; non-global view of "validity";
> possible social graph leakage
>
> (there's probably some other major scheme that i'm missing in this rough
> sketch)
>
> The trouble is, all of these schemes have places where they break down
> and fail in bad ways.  Manual verification fills in these gaps.  Without
> it, you either fail closed (locking users out of their services
> unnecessarily) or fail open (exposing users' communications to an
> adversary).
>
> So i think it's worthwhile to talk about good ways to do manual
> verification under common constraints.
>
> > That said, I recently created a ton of ssh
> > keys for testing purposes and I was reminded of the beauty of Adrian
> > Perrig's randomart hash visualization:
> >
> > +--[ RSA 2048]----+
> > |  . . .   .      |
> > | . . . E o       |
> > |.       + o      |
> > |..  .  o * .     |
> > |.. o    S o      |
> > |. o  ... .       |
> > | . . oo          |
> > |    o..          |
> > |     .o+.        |
> > +-----------------+
>
> I can't tell if this is a serious advocacy of randomart -- we've
> discussed it here before [0]; no one was advocating it and several folks
> expressed pretty deep skepticism that this is a useful representation
> for users.  do you think it's a good idea?  if so, in what contexts?
> surely it's terrible over the phone or on a cocktail napkin.
>
>         --dkg
>
> [0] see, for example, multiple mentions in the "useability of public key
> fingerprints" thread
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140311/1086a17b/attachment.html>