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 <[email protected]> > 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-** > authentication/global_**registry_of_dishonesty.html<http://eccentric-authentication.org/eccentric-authentication/global_registry_of_dishonesty.html> > [3] http://eccentric-**authentication.org/blog/2012/** > 10/23/a-blog-site.html<http://eccentric-authentication.org/blog/2012/10/23/a-blog-site.html> > [4] http://eccentric-**authentication.org/blog/2013/** > 06/02/an-end-run-around-**zookos-triangle.html<http://eccentric-authentication.org/blog/2013/06/02/an-end-run-around-zookos-triangle.html> > [5] http://eccentric-**authentication.org/blog/2013/** > 06/07/run-it-yourself.html<http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html> > > ______________________________**_________________ > cryptography mailing list > [email protected] > http://lists.randombit.net/**mailman/listinfo/cryptography<http://lists.randombit.net/mailman/listinfo/cryptography> >
_______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
