Re: [cryptography] Looking for earlier proof: no secure channel without previous secure channel
So basically, the way around having one insecure channel is to use so many insecure channels that the same attacker can't control them all. Which IRL means you run around between computers and check if what you published is available under the exact identity/keys you specified, and keep making up new names until you manage to get one of them widely propagated with your own keys, and then you keep using that identity. Note that one of the problems with this is a worse version of domain-squatting - a powerful attacker can register nearly *all* meaningful names faster than most regular people. However, this can be made harder with something like proof-of-work, which interestingly enough things like vanitygen provides right there in the keys - you specify a text string you want in your public key (or it's hash), and it generates keys until it finds a match. People are using this in Bitcoin, and people have done this for Tor .onion addresses. It could also be done for CJDNS and I2P's b32 domain names ([52-base32-characters-of-hash-of-public-key].b32.i2p). Make up a unique name and generate a unique key for it, and it's harder to do a quick MITM on it when you start trying to propagate it. On quantum encryption/key exchange that was mentioned before - that assumes just like any other connection that the MITM wasn't in place before the connection was first put in use. You can detect an attacker that shows up in between you and the node you are directly physically connected to, but if he's already there when you first connects then you can't know the difference. Whatever channel you use to verify the connection, you might as well just use that channel to exchange asymmetric public keys and skip everything quantum. 2013/6/7 Guido Witmond gu...@witmond.nl On 07-06-13 14:50, ianG wrote: On 7/06/13 14:45 PM, Ralph Holz wrote: Hi, What makes the silk road key the real public key is that it is the same key has everyone else uses.- that it is public. This simply falls back to an assertion made by a `trusted' entity, namely the `public', and is thus an authenticated credential. Well, yes or no or maybe. In practice, there is no 'entity' named the public [1]. Looking a bit closer, there are people, many of them. What broad publication allows is a low-cost way to ensure that most people have the same initial secret, and that most examples of any interference with that initial secret are cheaply discovered. PS: Leaving aside the obvious circular definition of trusted entity being one who we trust to do the authentication. In the above example, it reads absurdly: there is no such entity 'public' that decides to do the trusting of the non-existent-entity 'public'. This is what I try to do with my Eccentric-authentication scheme. [1] I make this 'public' more explicit with a global registry. It allows verification that a CA only certifies each Common Name only once. The price of this registry is mostly storage and lookups. A DHT-like storage would be perfect. There are no namecoin-like hashes to calculate. [2] There is no need for users to put *trust* in the global registry. The registry is not in a position to invalidate any certificates, nor create fake certificates. All trust comes from verifying that a CA (still) doesn't sign a Common Name twice. Only a CA is able to forfeit the trust he's earned by signing multiple certificates bearing the same Common Name. Even though the CAs (one for each web site) do not validate a users real identity, this verification of the uniqueness property allows the certificate (and the users' public key) to become an anonymous identity. Use: The idea is that bloggers at an ecca-authenticated blog write signed messages with the message signature attached to their blog entries. The user agent verifies these signatures against the verifiable unique certificate. This allows people to *identify* fellow bloggers by their certificate (Common name). [3] The registry operates as introducer. Once a person has communicated successfully with someone there is no need to look up their certificates at each use. This keeps the load on the registry low and improves scalability. With DNSSEC/DANE in the mix, we have another way around Zooko's Triangle [4] Try it: It's not only theory. I've got two demo sites and a proxy server to stand in for the user. It shows the Local CA bit and anonymous messaging. (notice it doesn't use the global registry idea, yet) [5] With regards, Guido Witmond. PS. This is a protocol to create anonymous accounts where anonymity is important. Don't use it to identify your employees, nor your customers when you run a bank. [1] http://eccentric-**authentication.org/http://eccentric-authentication.org/ [2] http://eccentric-**authentication.org/eccentric-**
Re: [cryptography] Looking for earlier proof: no secure channel without previous secure channel
On Fri, Jun 07, 2013 at 10:02:51AM +0300, ianG wrote: The big example here is of SSL. In v1 it was vulnerable to MITM, which was theoretically claimed to make it 'insecure'. In practice there was no evidence of a threat, and still little real evidence of that precise threat. Fixing the MITM in SSL v2 caused the utility to fall and costs to skyrocket, which meant that it failed in its overall mission and maintained its credit card mission only by much handwaving and ignoring of other issues. When it comes to browsers, the way SSL/HTTPS has been presented to users is maddening. Every time a user sees the scary unsigned SSL certificate warning we're basically telling the user that their security is worse with SSL than without. I've seen multiple comments on sites like slashdot by sysadmins and programmers who don't understand crypto discouraging the use of HTTPS unless you have a CA-signed certificate because it makes you vulnerable to a MITM attack... when HTTP is vulnerable as well. Somehow people actually have this misunderstanding. What browser vendors should be doing is to display http and https URLs identically in the URL field and focus on the Green URL side of things to make it clear when the connection is actually authenticated. It's probably not a bad idea for a *manually entered* https URL to result in a warning if the certificate is unsigned, but the general case should simply have identical behavior given the identical worst-case security. The PGP world is the same. We would be far better off if we focused on making PGP simple and easy enough that people actually use it; focusing on the web-of-trust does more harm than good. Again protection from passive evesdroppers is a huge improvement on the status quo even without any protection from active evesdroppers. For one thing active evesdroppers leave evidence of their actions. -- 'peter'[:-1]@petertodd.org 002ef32132cbc3d519800a1f348a51b3ee59f9686e52d92d8734 signature.asc Description: Digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Looking for earlier proof: no secure channel without previous secure channel
Precisely. You have no way of knowing anything about the alleged identity behind a key without having some form of interaction through a secure channel (like real-world interaction). On Jun 7, 2013, at 3:53 PM, Florian Weimer f...@deneb.enyo.de wrote: Practically speaking, this is true. Maybe I'm a bit naïve, but I expect it's difficult to model such global semantic concerns accurately, including the fact that you cannot actually use public keys as identities because in reality, no one wants to talk to a key. signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Looking for earlier proof: no secure channel without previous secure channel
We're starting to tread into very philosophical territory. I'd argue that users on the Silk Road (sellers especially) are, in fact, authenticated over very informal separate secure channels. One secure channel is that of the Silk Road website itself. By being on the website, it lends some credence to the idea that the owner of the key you are communicating with is who they claim to be. This, it could be argued, is a very fuzzy form of authentication. A second secure channel is the review system on the Silk Road. People reviewing the salesmen, perhaps using crypto to authenticate their reviews, represents a *very* informal kind of certification system/web of trust. This is another authentication channel. It's important to realize that an identity is more than just a name or an ID number. Most authentication systems only care about authenticating names and ID numbers, but other authentication systems (like the informal one used on the Silk Road) is about authenticating the part of someone's alleged identity that says I sell drugs and I won't screw you over somehow. It's not always Alice wants to talk to Bob. Sometimes it's A legitimate drug purchaser wants to talk to a legitimate drug vendor. The names don't matter, so they don't have to be authenticated over a secure channel. So I don't think it's accurate to say that people want to talk to the key. They actually want to talk to a specific thing behind the key. However, instead of wanting to talk to an identity that has the property of being named John Doe or what have you, like we usually do in crypto, they want to talk to an identity that has the property of being a drug salesman. On Fri, Jun 7, 2013 at 9:02 PM, James A. Donald jam...@echeque.com wrote: On 2013-06-08 6:53 AM, Florian Weimer wrote: you cannot actually use public keys as identities because in reality, no one wants to talk to a key. Again, Silk road is a counter example. That is a key that people do want to talk to. __**_ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/**mailman/listinfo/cryptographyhttp://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
