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 <[email protected] > 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 > [email protected] > https://moderncrypto.org/mailman/listinfo/messaging > >
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
