[messaging] Are we pursuing real solutions for security?
Christine Corbett Moran
corbett at alum.mit.edu
Tue Mar 11 14:22:33 PDT 2014
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
On Tue, Mar 11, 2014 at 10:12 PM, Daniel Kahn Gillmor <dkg at fifthhorseman.net
> 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
> 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
> 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 ; 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.
>  see, for example, multiple mentions in the "useability of public key
> fingerprints" thread
> Messaging mailing list
> Messaging at moderncrypto.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging