crypto renaissance

With ‘CryptoGate’ in full action, many people are trying to come
up with a solution. Some good, many bad.

Many people focus on the security aspect of cryptography. Although
necessary, it is not sufficient.

The thing most people take for granted is how to authenticate the
other end of your communication channel. With PGP/GPG you need a web
of trust to validate. WebID/FOAF tries to replicate that in
HTTPS. These trust connections are public knowledge. There is no
anonymity. And if you are not part of that network, you don’t have a
way to validate any of the keys.

X509 server certificates from the global certificate authorities are a
scam (due to the missing X500 directory that matches end point
identities to certificate authorities). Try to answer this one: Who is
the certificate authority of your bank’s web site?

End user client certificates from these same certificate authorities
are akin to digital passports, tying all use of it to one’s true
identity, for life. Besides they still suffer from the missing x500
directory. One can’t tell from the certificate, if Guido Witmond’s
certificate signed by Verisign is mine, a forgery, or someone else
with the same name.

Validate keys of total strangers

I’ve came up with my way of doing things. I believe the answer lies in
the fact that we need a way to exchange public keys between total
strangers, reliably. In a way that is backwards compatible with the
current web, as that’s what people are used to.

I call that effort Eccentric Authentication.

The central idea is that each website signs the client certificates for all
it’s customers. The site runs its own CA. The only (and utmost
important) requirement is that the user-chosen account name is unique
for the site. Users don’t have to provide email address, passwords, or
other identifying details. Certificates are anonymous. Especially when
Tor is used. Users will have a different identity at each site,
sometimes more than one at a single site.

The second thing is that whenever people write a blog or leave
comments, these messages are signed with their private key.
Other visitors at the site can recognize the message signature by the
fact that the CA is the one from the site.

This ties the message to the person holding the private key. But a
public key is not a human friendly identifier. The chosen
account name (as Common Name) in the signature is human friendly.

To protect against MitM attacks, we need a way to verify that the
site’s CA signs each account name only once. I propose we use a
central registry like CMU’s Perspectives but for client
certificates. Whenever a person signs up for a client certificate they
submit their certificate to this registry. Every once in a while
people look up to see if theirs is (still) the only one for their
account name at the site. The most important requirement for this
registry is that it cannot fake the answers, once a certificate has
been submitted, it cannot deny it has received it. It’s best if it is
set up as a distributed service.

These two ingredients, Local CAs that sign only their own clients and
the global registry, are sufficient to let total strangers communicate
privately and anonymously.

If a reader of this signed blog wants to, they can write an encrypted
message to the author of the blog using the public key in the
signature on the blog. A quick lookup at the registry will tell if
theirs is still the only certificate for the {account name, site name}

Authenticated anonymously

Once they’ve exchanged the first messages between them, and they
checked that both their account name and that of the other party have
the expected certificate at the registry, they’ve authenticated each
others public keys!

Two total strangers, who have never met, have been introduced by a
third party (the site) that also doesn’t know anything about the two.

The site disappears from the picture. Once authenticated, the people
can send a message (encrypted of course) with a delivery end point
that is independent from the site.

Global unique names

As we have a way to validate the account-name sitename tuple, we can
distribute public keys by just writing down this name. One can
introduce one other by telling this name. The recipient can look up and
see that the name points to one certificate. Here is the seed for a
web of connections. No nasty fingerprints to validate.

There is more.

With the site’s server certificate signed by the site’s own CA,
clients can match the client certificates for the site against the
site’s server certificate. This makes the CA’s root certificate the
identity of the site. This protects against phishing, as the
phishers cannot fake the CA’s root key. It won’t match.

It also creates censorship resistance. The site can change names, go
dark on onion sites. When the site owner creates a new certificate
with the same Root CA, the new site assumes the old identity. People can log in
again with their existing certificates.

I use DNSSEC and DANE to make sure that new people can find the
correct site. In combination with the registry, people can validate
that the DNS registries have not been manipulated.

It doesn’t take much.

All that’s needed to bootstrap this is a browser plug-in that does the
crypto work. As proof of concept, I made a web proxy to show how easy the user interface can be.

Please find it at Run it Yourself

If you have any questions, I’d happy to clarify. Just use plain email for now.

With Regards, Guido Witmond.