On 09/11/13 13:23, Paul Crowley wrote: > From the title it sounds like you're talking about my 2007 proposal: > > http://www.lshift.net/blog/2007/11/10/squaring-zookos-triangle > http://www.lshift.net/blog/2007/11/21/squaring-zookos-triangle-part-two > > This uses key stretching to increase the work of generating a colliding > identifier from 2^64 to 2^88 steps.
Hi Paul, Reading your blog, you've came up with a way to encode a public key into a much more memorable string of words. Although the user is not free to choose the name. I go a bit furhter in that direction. In Eccentric Authentication, the usernames (nicknames) are composed of a domain name and an account name. Just like email addresses. The domain name is given by the site, the account name is your choice. As long as it is unique for the site. (There can be a foo at google, a foo at gmail, a foo at yahoo). Just as people expect email addresses to be unique too. To create a full name, the user chooses a site and opens an account there. The account name is free to choose by the user (subject to availabilty and site rules). If the requested account name is not yet given, the sites' local CA signs the name (and the users' public key) into a client certificate. You can use this certificate to log in at the site, but also to encrypt and sign messages. To make names Zooko-proof, you need to make sure that once a name is given (bound to a value), it cannot be changed anymore. For that I use a form of Certificate Registry for logging. Once you've acquired a client certificate, you send it to the registry. It stores the certificate keyed by it's full name. Ie, anyone can lookup the name at the registry and retrieve your certificate. This registry protects against man in the middle attacks. When you encounter a signed message somewhere, you lookup the certificate in the registry. You should expect a single answer, namely, the certificate that matches the signature on the message. If you receive the matching certificate, it is proof that the full name is unique and that the public key in the certificate can be used. If you receive a single answer with a different certificate, you know that someone is trying a mitm between you and the other party. You submit the one that you've discovered to the registry so it will be there for everyone to see. If there are multiple certificates (bearing that same full name) signed by the same CA, it's them who became dishonest. The protocol explicitly calls the site Dishonest. If there are multiple entries bearing the same name but from different CA's, there has been a DNSSEC registry hack. The site should change DNSSEC-registrar. And the key is useless. In general, every once in a while you check that your name is still unique, just to make sure that the site keeps its requirement to hand out each name only once. You also check out the names of new communication partners, just before and slightly longer after first contact. When you still only find your and their names with the expected nickname, there has been no mitm and you have validated that persons public key. (As described in my blog "The Holy Grail of Cryptography" [0]. You can keep using this persons public key, even if the site gets compromised later. Just add it in your address book. I hope it has become clear how I square the triangle. Feel free to point out omissions, request clarifications. With kind regards, Guido Witmond 0: http://eccentric-authentication.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
