Re: [cryptography] Nirvana
On Fri, Sep 23, 2011 at 1:46 AM, James A. Donald jam...@echeque.com wrote: On 2011-09-23 8:33 AM, Nico Williams wrote: In your view then, is the alternative at all a public key based crypto system? If yes, is it SSH (or SSH-like) trust on first contact or something else? In order to shop, one needs a third party mediating transactions *THEY* should issue certificates. The Visa certificate should signify This merchant is trusted by Visa to accept Visa. And further, you should have a client app on your computer for dealing with shared secrets, which is only capable of attempting a visa payment with an entity trusted by Visa. Wasn't that what SET did? ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Nirvana
On 23/09/11 08:33 AM, Nico Williams wrote: On Sun, Sep 18, 2011 at 11:22 AM, M.R.makro...@gmail.com wrote: In your view then, is the alternative at all a public key based crypto system? If yes, is it SSH (or SSH-like) trust on first contact or something else? It could vary. For low-security applications, like blog comments, yes, leap-of-faith will do. For a medium-security application, like shopping (where systems like credit card fraud protection render the risk to the user low), security bootstrapped from leap-of-faith + trust-building or trusted third parties will probably do. I would go TOFU -- trust-on-first-use -- here alone, but replaceable by certs signed by other parties, in a compatible fashion. I don't understand the leap-of-faith metaphor. It seems to me that trusting a CA is a leap of faith given that we have to trust all of them, and we know next to nothing about them. Bad risk analysis there, because we've outsourced it to unknown parties, via other unknown parties. Whereas when we are doing the TOFU mechanism, we can incorporate all of our local knowledge and decide whether there is any risk in dealing with this merchant. Good risk analysis. For high-security applications (like banking) you'll generally want to bootstrap security via something else, either an off-line interaction, or a trusted third party that can authenticate relatively few peers to you (and thus is probably more trustworthy w.r.t. verification of your peer's credentials). There is another level of security above that which I guess we'll have to call ultra-security [0]. This is for real time transactions (payment systems or trading) and/or high values, and/or natsec things. In ultra-sec, we'd download a client securely the supplier, and put it on to a single purpose machine. iang [0] Which I call high security. Banking I generally call medium security ... anything using web browsers isn't really serious IMHO. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Nirvana
Ben Laurie b...@links.org writes: Wasn't that what SET did? No. Or at least buried way, way down in a hidden corner there was something that was a bit like that, sort of like painting one of the toenails on an elephant, but the vast mass of the rest overwhelmed that one bit. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Nirvana
And further, you should have a client app on your computer for dealing with shared secrets, which is only capable of attempting a visa payment with an entity trusted by Visa. I don't see how to do that in a useful way without non-programmable hardware. We've seen PC-based malware do pretty much any MITM attack you can imagine. R's, John PS: I was impressed by the malware that redrew images in which the bank had put a text representation of the transaction to be approved. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL is not broken by design
On Thu, Sep 22, 2011 at 4:46 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ben Laurie b...@links.org writes: Well, don't tease. How? The link I've posted before (but didn't want to keep spamming to the list): http://www.cs.auckland.ac.nz/~pgut001/pubs/pki_risk.pdf That was a fun read and I mostly agree, but it raises some questions... a) Key continuity is nice, but ... are you swapping one set of problems for another? What happens when I lose my key? How do I roll my key? I just added a second server with a different key, and now a bunch of users have the wrong key - what do I do? How do I deal with a compromised key? b) Entering passwords on a new site: again, nice, but how will you detect sites that merely mimic password entry? Wide acceptance would lead to avoidance techniques that seem hard to detect. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] SSL is not broken by design
On Sep 23, 2011, at 11:17 AM, Ben Laurie wrote: On Thu, Sep 22, 2011 at 4:46 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Ben Laurie b...@links.org writes: Well, don't tease. How? The link I've posted before (but didn't want to keep spamming to the list): http://www.cs.auckland.ac.nz/~pgut001/pubs/pki_risk.pdf That was a fun read and I mostly agree, but it raises some questions... a) Key continuity is nice, but ... are you swapping one set of problems for another? What happens when I lose my key? How do I roll my key? I just added a second server with a different key, and now a bunch of users have the wrong key - what do I do? How do I deal with a compromised key? Great rhetorical questions, Ben. You nail it. Continuity is great, but it has its own set of problems that include all the ones you mention. Rolling keys is the easiest one of them and can be solved pretty much the same way. But all the others are problems that continuity introduces. I brought up these issues in my long rant. Continuity can solve some, but not all of the problems. Jon ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Nirvana
And further, you should have a client app on your computer for dealing with shared secrets, which is only capable of attempting a visa payment with an entity trusted by Visa. On 2011-09-24 4:06 AM, John Levine wrote: I don't see how to do that in a useful way without non-programmable hardware. We've seen PC-based malware do pretty much any MITM attack you can imagine. Most computers are not controlled by malware, and the malware argument is as much an argument against existing ssl/https/pki as it is against any alternative to ssl/https/pki ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Nirvana
Also, what if we had real cryptographic money, with anonymity? In other words: the payments system cannot be the trusted third party for everything. On 2011-09-24 4:08 AM, John Levine wrote: Then malware would steal the crypto wallets. See Bitcoin. Yet Bitcoin, nonetheless, works. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
