On 2/05/2014 13:06 pm, Marcus Brinkmann wrote: > On 05/01/2014 10:25 AM, Ben Laurie wrote: >> On 1 May 2014 08:19, James A. Donald <jam...@echeque.com> wrote: >>> On 2014-04-30 02:14, Jeffrey Goldberg wrote: >>>> >>>> On 2014-04-28, at 5:00 PM, James A. Donald <jam...@echeque.com> wrote: >>>> >>>>> Cannot outsource trust Ann usually knows more about Bob than a >>>>> distant >>>>> authority does. >>>> >>>> >>>> So should Ann verify the fingerprints of Amazon, and Paypal herself? >>> >>> >>> Ann should be logging on by zero knowledge password protocol, so that >>> the >>> entity that she logs on to proves it already knows the hash of her >>> password. >> >> EXACTLY!!! >> >>> ZKPP has to be in the browser chrome, not on the browser web page. >> >> This seems obvious, but experiments show users do not understand it. >> We have yet to find a satisfactory answer to a trusted path for >> ordinary users. > > So where it really mattered we got two-factor authentication (by mobile > phone) instead.
Right, the European solution, send the Tx to the phone by SMS and get the user to type in a code that authenticates that Tx only. Pop quiz: does the SMS/Tx system still work if we strip HTTPS off the browser? > I like the trade-off. Using another untrusted path on > a different network and machine for a probabilistic guarantee seems more > reasonable to me than trying to build a trusted path on a single > machine, which was ambitious at the best of times, before we knew for a > fact that we can not trust a single embedded integrated circuit in any > device in the world. And that is not even considering the usability and > accessibility issues of all the fancy trusted path solutions that I've > seen. > > Security researchers can not even guarantee that the status light of the > camera is on when it is recording images. iang _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography