Re: Encrypting content of hidden service descriptors

[Roger Dingledine <arma@xxxxxxx>]

On Sat, Apr 14, 2007 at 08:01:21PM +0200, Karsten Loesing wrote:
> The reason why I asked the question is, that I am rethinking the format
> of rendezvous service descriptors at the moment. And there still is this
> idea around of encrypting the descriptor content which is, as you wrote,
> not completely solved.

Right. I remember a discussion a couple years ago about how to encrypt
the hidden service descriptors. I wanted three things at once:

a) The places that store and serve the descriptors can't learn the
introduction points,
b) But they can make sure they're signed correctly and can pick out the
newest descriptor.
c) Select clients can learn them through some extra key or whatever
they're given.

Doing all three of these with just one key (or derivatives of that key)
seems hard. It probably requires crypto magic that I don't have.

An easier option might be to use two keys. I haven't worked out the
details, which means all the hard work still remains ;), but the idea
would be that we'd have a signing key which is publicly known, and
the name, timestamp, signing key, and signing key signature would be
clearly visible to everybody. The rest of the descriptor would be the
introduction points, encrypted with the second (encryption) key. Then
the client would be given both keys (e.g. x-y.onion), whereas the public
only knows the signing key.

The next step would be fixing it up so knowing the encryption key doesn't
necessarily mean you can always decrypt things in the future. Rotating
the encryption key periodically might do it, or we could do something
more complex.

But of course, if the rest of the protocol remains the same, then
the adversary can still enumerate introduction points pretty easily
by attempting to introduce himself at each Tor server one by one
using the public onion name. Fixing that starts to make things more
complicated. Hm.

> The question is, though, whether we need to solve it now. When
> distributing the directory for hidden service descriptors, everyone
> could be responsible for storing a descriptor and could read it, if it
> is unencrypted. At the moment you as hidden service provider need to
> trust only the five directory authorities, in a decentralized design you
> further need to trust each of the 500 DHT nodes...

Right. We do need to clarify our threat model and goals here. (By the way,
it's only 3 directory authorities: just the ones that offer the HS flag,
which coincidentally are the ones that offer the V1 flag.)

When we originally designed this, we had no intention of keeping
descriptors private. Putting them on the dirservers was just a hack
because I didn't have anywhere better to put them. But the notion that the
dirservers give them more "secrecy" has gradually sprung up since then. So
the question is: so what? What happens if all descriptors are public?

First, you can DoS the intro points of a hidden service, even if the
hidden service hasn't revealed itself to you. This is an issue, but if
you want to enumerate hidden services, you have other options -- a less
efficient approach would be to run a bunch of stable nodes and hope you
get picked as an intro point a lot.

Second, you can visit a hidden service, even if it hasn't revealed itself
to you. You won't know what ports it supports, but you can portscan the
whole thing, and besides it's probably just on port 80 anyway. Is the
answer that hidden services that want authorization should implement
it end-to-end (e.g. http auth) and not try to keep their address itself
a secret?

What other issues are there if each hidden service descriptor is public?
Rather than postponing this mail another day while I sleep, I'm going to
send it and hope other people bring up the other issues. :)

Thanks,
--Roger