<div dir="ltr">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 </div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Mar 11, 2014 at 10:12 PM, Daniel Kahn Gillmor <<a href="mailto:dkg@fifthhorseman.net" target="_blank">dkg@fifthhorseman.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">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. </div>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. <div class=""> > 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+. | > +-----------------+ </div>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 <a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a> <a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a> </blockquote></div> </div>