[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #33712 [Core Tor/Tor]: Design a PoW/credential scheme for HS DoS defence

#33712: Design a PoW/credential scheme for HS DoS defence
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, tor-dos, network-team-       |  Actual Points:
  roadmap-2020Q1, network-health, research       |
Parent ID:  #31223                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by asn):

 The strawman proposal of a basic PoW-over-INTRO scheme is:

 1) Client sends INTRO1 with a special PoW extension
 2) Intro sends back INTRO_CHALLENGE to client with a nonce
 3) Client crafts PoW with that nonce and sends it back to client
 4) Intro validates PoW difficulty and either forwards intro to service or
 rejects.

 This can come with various variants like the service encoding the nonce
 and parameters [https://lists.torproject.org/pipermail/tor-
 dev/2019-June/013882.html in the descriptor] in an attempt to cut the
 challenge round trip (with extra complexity coming from replay detection
 etc.), or with clients doing PoW bidding (or "staking") as proposed in the
 recent call.

 ----

 I wanted to mention this strawman proposal as a basic building block after
 reading that mtp-argon2 type of protocols require way too much space for
 proving. I was wondering if the above strawman approach but using argon2
 as the hash function for memory-hardness would work for us, but then I
 understood that the space requirement is caused by using a merkle tree as
 part of enforcing the memory-hardness; as in that argon2 itself is not
 sufficient to enforce full memory-hardness.

 So how do we go from a simple PoW scheme like the above, to something that
 works for us? Is it just the memory-hardness that we are losing by using
 the strawman approach over a more hardcore mtp-argon2 approach?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33712#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs