On 2019-06-20 00:19, Watson Ladd wrote:
On Tue, Jun 18, 2019 at 6:29 PM Chelsea Holland Komlo
<me@xxxxxxxxxxxxxxxx> wrote:
There are a couple approaches to consider.
POW via hashing goes for a relatively simple to implement approach.
However, this incurs a high cost for all clients, and also environmental
damage, per previous email.
Another approach similar to the above (but more environmentally
friendly) can be Proof of Storage (or proof of space), as in
https://eprint.iacr.org/2013/796.pdf
With both of the above approaches, there will be a tradeoff to what the
cost is to deter a would-be attacker, versus the cost to real but
bandwidth/cpu limited clients, such as on mobile platforms.
More involved approaches include anonymous blacklists/whitelists,
blinded tokens, etc. Previous work has been done in this space, here is
one example:
https://crysp.uwaterloo.ca/courses/pet/F11/cache/www-users.cs.umn.edu/~hopper/faust-wpes.pdf
Privacy Pass has already been integrated into Tor Browser. Perhaps
work could be done to use it here?
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.
Better understanding the requirements of the system from George and
David will help define which approach is acceptable given the tradeoffs.
For example, I imagine accessing onion services should not be restricted
to clients from a web browser.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev