On 2019-06-20 00:19, Watson Ladd wrote: > > Privacy Pass has already been integrated into Tor Browser. Perhaps > work could be done to use it here? As I said above, any oblivious PRF scheme like privacy pass violates privacy *if* you can supply different keys to different users. We cannot derive the OPRF key from the HS key, so this requires some messy solution like certificate transparency or more likely zero-knowlege proofs. If otoh you use blind signatures then the blind signing key can be derived from the HS key, which avoids this complexity. We’ve new complexity in that blind signatures using an Edwards curve really suck, but we should be fine so long as only the soundness is weak, not the blindness. I have not refreshed my memory on this point yet. On 20 Jun 2019, at 15:41, Chelsea Holland Komlo <me@xxxxxxxxxxxxxxxx> wrote: > An approach akin to Privacy Pass could be an option to avoid serving > challenges to clients with each request (see reference to anonymous > tokens above), but it cannot be a drop in fix, of course. Furthermore, > an acceptable POW or POS scheme still needs to be selected, the > tradeoffs of which we are currently discussing. Why? Just rate limit connections by adding artificial latency. If an HS operator turns on the DoS defences, then they are responsible for judging the client’s behaviour and notifying their Tor to issue blind signed tokens. At that point the HS tor invites the client’s tor to submit blinded tokens, which the HS tor signs and sends back, and the client’s tor unblinds and uses. It’s only three round trips I think. If the HS never notifies tor to issue tokens, then the HS just behaves sluggishly, but a correct configuration gives an operator complete control over issuing tokens. Jeff
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev