[tor-dev] A modest proposal for a petname system in ideas/xxx-onion-nyms.txt

Steven Murdoch Steven.Murdoch at cl.cam.ac.uk
Sun Jan 1 20:06:18 UTC 2012

Hi Jacob

On 17 Dec 2011, at 01:14, Jacob Appelbaum wrote:
>  A nym will expire if either the HS goes offline for longer than a
> given time
>  threshold or if he explicitly requests removal of the association to that
>  particualr nym. This allows dynamic reallocation of nyms and avoids nym
>  squatting.

This may be stating the obvious, but a problem here is someone could DoS the hidden service for sufficiently long they could steal the nym. If the attacker is smart, they will only do the DoS when the nym authority is checking (which suggests the nym authority should check at random intervals).

Alternatively, the attacker could hack the hidden service and publish a release request. It would be nice if it were easy to run a hidden service with no security vulnerabilities but that is not going to be the case any time soon.

One fix to the DoS problem is to permanently bind a nym to an onion address, but as you point out allows nym squatiting and other badness. This however does not help if the attacker has hacked the hidden service and obtained its private key.

A potential fix to the hacking vulnerability is to bind the nym to a key ID, where the private key can be kept offline. If the attacker hacks the hidden service and obtains the hidden service private key the legitimate nym owner can recover by publishing a new binding request with the same key ID, but signing the request with a higher serial number than before.

However, this massively complicates what was otherwise a relatively simple proposal, and gives marginal benefit in what I expect to be the common case: where the nym binding private key would be stored online and thus precisely as vulnerable to compromise as the hidden service key.


More information about the tor-dev mailing list