Intro PoW: add `hs_id` binding to avoid pow-stealing attack.
Hi! Please forgive me if this attack doesn't work for some reason I didn't see from reading the spec.
Suppose that the attacker is running a popular onion service, and they want to attack another onion service.
To do so, they use that onion service's PoW seed C in their own
descriptors. They use the same suggested-effort, or higher.
Now, every time a client connects to the attacker's onion service,
they provide the attacker with a Nonce,Solution pair that will
also work as a Nonce,Solution pair against the target website.
This lets the attacker mount a DoS against the target without having
to generate the PoWs themselves.
Two factors make this attack less severe than it might be otherwise:
- It requires the attacker to actually have an onion service that a lot of users are connecting to, or to trick a lot of users into connecting to their service.
- Using the same seed is (in principle) detectable, and the attacker should expect to be caught sooner or later.
Nonetheless, I figure it's worth solving this, since the solution is
so easy. The easiest way to solve this attack would be to include
the identity of the onion service KP_hs_id (or a hash of it)
as part of the PoW challenge.
While we're making this change, I think it would be a good idea to also include a domain separator string in the PoW challenge, so that we can require PoW elsewhere in our protocol later on if we have to.
Otherwise we'll have to worry about attacks where somebody reuses an "introduce-pow" seed as a "circuit-extension-pow" seed, or something.
This would also lower the odds of somebody else accidentally designing a protocol whose PoW could be reused as PoW for ours, or vice versa.