The --use-tor option

Jacob Appelbaum jacob at
Tue Oct 20 20:27:49 CEST 2015

On 10/20/15, Daniel Kahn Gillmor <dkg at> wrote:
> On Tue 2015-10-20 13:31:58 -0400, malte at wrote:
>> Quoting Daniel Kahn Gillmor (2015-10-20 16:57:53)
>>> On Mon 2015-10-19 10:54:49 -0400, Malte wrote:
>>> > On Monday 19 October 2015 15:03 Werner Koch wrote:
>>> >
>>> >> This is not complete because DNS lookups are leaking.  This could be
>>> >> fixed […]
>>> >
>>> > Maybe Kristian Fiskerstrand would be willing to set up an Onion Service
>>> > for
>>> > the SKS-Pool that could be used by default?
>>> I don't think this makes much sense -- there are already keyservers that
>>> offer hidden services (e.g. qdigse2yzvuglcix.onion), but they are
>>> individual keyservers.
>> Ok. Then let's use that one. My main concern was the DNS resolution
>> problem.
> Well, that's just one individual keyserver.  If you configure that one
> and it dies you've gotta change your settings.  A pool has the usual
> advantages of failover, etc.
> Given that hidden services have the name bound to the public key, i'm
> not sure how you'd operate a hidden service pool without sharing the
> associated secret key among all hosts.  Has anyone done any research on
> high-availability hidden services?

Yeah - the best person in the world is Donncha. I've cc'ed him.

He wrote OnionBalance.


In short: one .onion name can be used to load balance over many other
.onions run by many other people. The main .onion does not need access
to the private key of the other onions.

We could have ten SKS servers each with their own .onion {{0-9}.onion}
name and then one .onion shipped with GnuPG, for example. We could
even have a dozen such names in GnuPG each backed by ~10 .onions, for
example. The nice thing about a .onion name is that it means that a
service can be hidden behind a NAT - it makes a name end to end
encrypted, geographically anonymized and *reachable* as long as the
Tor client providing the name is able to get online. Hooray, lots of
problems solved! New problems coming up soon enough!

All the best,

More information about the Gnupg-devel mailing list