Pure Python HTTPS Server

[Trevor Perrin]

Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote in message news:<7xd67zatic.fsf at ruckus.brouhaha.com>...
> trevp at trevp.net (Trevor Perrin) writes:
> > > Where do you get the fingerprint?
> > 
> > Through the same channel that you used to acquire the email address.
> 
> Well, no.  That channel doesn't have to be secure.  If you think it's
> secure, you may as well use it for secret keys.  Aha you say, it only
> has to be secure against tampering, not mere eavesdropping.

Exactly!

>  But if
> you've got a definite way to secure it against tampering, you may as
> well also secure it against eavesdropping.

Exchanging an "authentic" piece of data is much easier than exchanging
a secret one.

For one thing, authenticity is additive:  Say I list my fingerprint at
the bottom of every email, print it on my webpage and business cards,
and list it in directories.  You can check my fingerprint through
multiple channels to attain more confidence in it than any single
channel provides.

By contrast, secrecy is destroyed by broadcasting, so you and I would
need a single, highly-secure channel for a shared-secret.


> 
> > Put it this way: If you acquire someone's address through a secure
> > channel, then you can use that same channel for fingerprint
> > distribution.  If you acquired their address through an *insecure*
> > channel, then there's no point in using a PKI-provided (address,
> > public key) binding, since the address could be bogus.
> 
> Yes, but if the address is bogus and the public key is good, then
> someone intercepting the encrypted traffic can't read it.

I wasn't clear.  PKIs often map an address to a public key.  If you
input a bogus address to the PKI (i.e. an address chosen by an
attacker), you'll get back a bogus key.

So this sort of PKI *assumes* a tamper-proof channel for distributing
addresses.  Otherwise, garbage in; garbage out.  But in the presence
of such a channel, the PKI is superfluous.  Worse than superfluous: it
*reduces* security by adding an unnecessary point of failure.


> > Here's some good writings about this approach:
> > http://trevp.net/cryptoID/cryptoID.html
> 
> This paper begins
> 
>     Abstract: In this paper, we argue that person-to-person key
>     distribution is best accomplished with a key-centric approach,
> 
> However the idea of certificates is to do away with the need for
> person-to-person key distribution.  

It's poorly phrased, by "person-to-person key distribution" I meant
"key distribution in support of person-to-person communications" (like
email, VoIP, etc.).

However, you're right: certificates *do* try to automate key
distribution so it doesn't require human involvement.

That forces people to explain all their trust relationships and
requirements to the computer, so that it can process certificate
graphs on their behalf and calculate which public keys are acceptable
to them.

The problem is that people's trust relationships and requirements are
complex and context-dependent, and thus difficult to express in a
machine-usable form (look at PGP's web of trust, which is both too
crude to model real-world trust relationships, and too complicated for
most people to use).

Furthermore, people have access to channels which could potentially be
used for key distribution which software has no knowledge of
(face-to-face contact, business cards, paper directories, etc.).
 
So instead of trying to automate key distribution, we should try to
make it easy for people to perform it themselves.  Fingerprints are
the best way to do that, in my opinion.

Anyways, that sums up that paper, you can skip it now :-)...


> 
> > http://www.waterken.com/dev/YURL/
> > http://zooko.com/distnames.html
> 
> I'm presuming these are along similar lines as the first.

I think they share a theme, at least, which is the power of cutting
out the middleman and using cryptographic identifiers directly.


Trevor