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


Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

Reply via email to