Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
Why do we need to send a challenge to a client on every request? No, it is only the first time when connecting an onion and moreover this should be enabled only when the configured rate limit / antiDoS is reached. SO actually a client will be connecting to the onion like always: with no PoW. If the Intro Point reaches a configured limit, then, it starts challenging the client, only the first time, the first request to that onion. Someone said that my design of adding an extra round to make the PoW step was bad, yes, we could use something unique to that circuit based on ntor. BUT, what is better for performance? Is sending an extra cell better than computing PoW always? etc. -If you add an extra step for PoW: you can enable it only when needed: 1) no DoS? client connects like always and do not make a PoW. 2) DoS? client receives a challenge and computes a PoW. -If you do not add an extra step there is no dynamic way to enable or disable PoW. You bypass the extra step but the client needs to compute PoW every time. The only config aviable is service descriptor where onion can put the "enable pow" and client reads it and sends the PoW to I.P. unless you wanna build something more complex... On 20/6/19 15:41, Chelsea Holland Komlo wrote: On 2019-06-20 00:19, Watson Ladd wrote: On Tue, Jun 18, 2019 at 6:29 PM Chelsea Holland Komlo 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
> 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. Actually there is a method to use oblivious PRFs without sharing secrets, which then makes the HS key itself usable: Just check the oblivious PRF token at the HS itself, not at the introducer. If the token checks out then the HS responds quickly, but if not then it responds after some delay. Introducers do nothing different in this design, but introduce cells can contain more data. > 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. There is a tricky one-more-forgery attack on Schnorr blind signatures, but not afaik any key recovery attack: https://www.iacr.org/archive/crypto2002/24420288/24420288.pdf As a defence, one could do blind signatures in G^3 requiring three scalar multiplications per signature from both signer and client, but limiting the forgery count to 1 per 63 signatures, which sounds acceptable. https://www.math.uni-frankfurt.de/~dmst/teaching/SS2012/Vorlesung/EBS5.pdf We’d need to work out if using some key derived from the HS key works however because we must avoid creating a signing oracle for HS keys too. So.. Do you want the filter at the introducer or at the HS itself? Jeff signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
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 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 signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
On 2019-06-20 00:19, Watson Ladd wrote: > On Tue, Jun 18, 2019 at 6:29 PM Chelsea Holland Komlo > 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
Watson Ladd: > On Tue, Jun 18, 2019 at 6:29 PM Chelsea Holland Komlo > 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? Where do you see that is has been integrated? As far as I know that's not the case even though there are still plans to evaluate the latest iteration closer to get a better understanding about whether it would be good to integrate it. [snip] Georg signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
On Tue, Jun 18, 2019 at 6:29 PM Chelsea Holland Komlo 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? > > While designs using a token-based approach such as what Jeff mentions > below may require more design/thought up front, the benefit is that > clients won't be penalized every time they connect to an onion service. > Considering the goal of scaling of the Tor network and of "onions > everywhere", this seems like a good tradeoff. > > > On 2019-06-16 18:03, Jeff Burdges wrote: > > As a rule, proof-of-work does not really deliver the security > > properties people envision. We’ve no really canonical anti-sibel > > criteria in this case, but maybe some mixed approach works: > > > > First, introduction points have a default mode in which they rate > > limit new connections and impose some artificial latency. Second, an > > onion service can issue rerandomizable certificates, blind signature, > > or oblivious PRFs that provide faster and non-rate limited access > > through a specific introduction points. > > > > Coconut would suffice for the rerandomizable certificates of course, > > but sounds like overkill.. and slow. > > > > We should consider an oblivious PRF for this use case too: > > > > It’s easy to make an oblivious PRF from the batched DLEQ proof > > implemented in > > https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs I suppose > > Tor might adapt this to not use Ristretto, or maybe choose an Ed25519 > > to Ristretto map, but regardless the whole scheme is not too much more > > complex than a Schnorr signature. > > > > We require the oblivious PRF secret key be known by both the > > introduction point for verification and the onion service for issuing. > > In this, we do not share the oblivious PRF key among different > > introduction points because introduction points cannot share a common > > double redemption database anyways. > > > > I’m worried about different oblivious PRF keys being used to tag > > different users though. There are complex mechanisms to prevent this > > using curves created with Cocks-Pinch, but.. > > > > We could simply employ blind signatures however, which avoids sharing > > any secrets, and thus permits binding the key uniquely to the hidden > > service. As a rule, blind signatures require either slow cryptography > > like pairings or RSA, or else issuing takes several round trips and > > have weak soundness. I think weak soundness sounds workable here, > > although I’m no longer sure about all the issues with such scheme. > > > > Best, > > Jeff > > > > p.s. We’re hiring in security > > https://web3.bamboohr.com/jobs/view.php?id=38 and several research > > areas like cryptography https://web3.bamboohr.com/jobs/view.php?id=29 > > > > > > > > ___ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- "Man is born free, but everywhere he is in chains". --Rousseau. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
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 While designs using a token-based approach such as what Jeff mentions below may require more design/thought up front, the benefit is that clients won't be penalized every time they connect to an onion service. Considering the goal of scaling of the Tor network and of "onions everywhere", this seems like a good tradeoff. On 2019-06-16 18:03, Jeff Burdges wrote: > As a rule, proof-of-work does not really deliver the security > properties people envision. We’ve no really canonical anti-sibel > criteria in this case, but maybe some mixed approach works: > > First, introduction points have a default mode in which they rate > limit new connections and impose some artificial latency. Second, an > onion service can issue rerandomizable certificates, blind signature, > or oblivious PRFs that provide faster and non-rate limited access > through a specific introduction points. > > Coconut would suffice for the rerandomizable certificates of course, > but sounds like overkill.. and slow. > > We should consider an oblivious PRF for this use case too: > > It’s easy to make an oblivious PRF from the batched DLEQ proof > implemented in > https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs I suppose > Tor might adapt this to not use Ristretto, or maybe choose an Ed25519 > to Ristretto map, but regardless the whole scheme is not too much more > complex than a Schnorr signature. > > We require the oblivious PRF secret key be known by both the > introduction point for verification and the onion service for issuing. > In this, we do not share the oblivious PRF key among different > introduction points because introduction points cannot share a common > double redemption database anyways. > > I’m worried about different oblivious PRF keys being used to tag > different users though. There are complex mechanisms to prevent this > using curves created with Cocks-Pinch, but.. > > We could simply employ blind signatures however, which avoids sharing > any secrets, and thus permits binding the key uniquely to the hidden > service. As a rule, blind signatures require either slow cryptography > like pairings or RSA, or else issuing takes several round trips and > have weak soundness. I think weak soundness sounds workable here, > although I’m no longer sure about all the issues with such scheme. > > Best, > Jeff > > p.s. We’re hiring in security > https://web3.bamboohr.com/jobs/view.php?id=38 and several research > areas like cryptography https://web3.bamboohr.com/jobs/view.php?id=29 > > > > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
As a rule, proof-of-work does not really deliver the security properties people envision. We’ve no really canonical anti-sibel criteria in this case, but maybe some mixed approach works: First, introduction points have a default mode in which they rate limit new connections and impose some artificial latency. Second, an onion service can issue rerandomizable certificates, blind signature, or oblivious PRFs that provide faster and non-rate limited access through a specific introduction points. Coconut would suffice for the rerandomizable certificates of course, but sounds like overkill.. and slow. We should consider an oblivious PRF for this use case too: It’s easy to make an oblivious PRF from the batched DLEQ proof implemented in https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs I suppose Tor might adapt this to not use Ristretto, or maybe choose an Ed25519 to Ristretto map, but regardless the whole scheme is not too much more complex than a Schnorr signature. We require the oblivious PRF secret key be known by both the introduction point for verification and the onion service for issuing. In this, we do not share the oblivious PRF key among different introduction points because introduction points cannot share a common double redemption database anyways. I’m worried about different oblivious PRF keys being used to tag different users though. There are complex mechanisms to prevent this using curves created with Cocks-Pinch, but.. We could simply employ blind signatures however, which avoids sharing any secrets, and thus permits binding the key uniquely to the hidden service. As a rule, blind signatures require either slow cryptography like pairings or RSA, or else issuing takes several round trips and have weak soundness. I think weak soundness sounds workable here, although I’m no longer sure about all the issues with such scheme. Best, Jeff p.s. We’re hiring in security https://web3.bamboohr.com/jobs/view.php?id=38 and several research areas like cryptography https://web3.bamboohr.com/jobs/view.php?id=29 signature.asc Description: Message signed with OpenPGP ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
juanjo writes: > On 13/6/19 12:21, George Kadianakis wrote: >> Is this a new cell? What's the format? Are these really keys or are they >> just nonces? > > Yes sorry, they are nonces. > > > This was only a proposal for a proposal. > >> Is this a new cell? What's the format? Are these really keys or are they >> just nonces? >> >> IMO we should not do this through a new cell because that increases the >> round-trip by one. Instead we should just embed the PoW parameters in >> the onion service descriptor and clients find them there. > Yes, this is a new cell triggered only when DoS limit is reached. > > We can't embed it on the onion service descriptor because the attacker > could precompute the PoW and make a dictionary attack. The IPKey (will > be a nonce) should unique for each new connecting client that wants to > send the INTRODUCE2. > > What we want this way is increasing the cost of an attacker by many > times vs only a little overhead to the I.P. > I see. So you were going for an interactive PoW protocol. I wonder what else we can get if we admit we want interactive. Can we get a CAPTCHA? What else? Still, I think the above protocol can be optimized to not require an extra round trip (extra round trips are bad for the network and for the intro point): For example, in place of an IPKey nonce that the IP explicitly sends to the client, we could use some sort of unpredictable crypto object from the circuit setup (e.g. ntor) between the client and intro point. >> That looks like a naive PoW scheme. It would perhaps be preferable to >> try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to >> minimize the advantage of adversaries with GPUs etc.? Are there any >> good such schemes? >> >> Also services should definitely be able to configure the difficulty of >> the PoW, and IMO this should again happen through the descriptor. > That PoW scheme was just a simple example. We should find the right > choice. Something hard to find but easy to check. > Yep. We should indeed find the right choice here. I have briefly tried and failed to find papers that compare PoW schemes in a useful way for this project. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
On 13/6/19 12:21, George Kadianakis wrote: Is this a new cell? What's the format? Are these really keys or are they just nonces? Yes sorry, they are nonces. This was only a proposal for a proposal. Is this a new cell? What's the format? Are these really keys or are they just nonces? IMO we should not do this through a new cell because that increases the round-trip by one. Instead we should just embed the PoW parameters in the onion service descriptor and clients find them there. Yes, this is a new cell triggered only when DoS limit is reached. We can't embed it on the onion service descriptor because the attacker could precompute the PoW and make a dictionary attack. The IPKey (will be a nonce) should unique for each new connecting client that wants to send the INTRODUCE2. What we want this way is increasing the cost of an attacker by many times vs only a little overhead to the I.P. That looks like a naive PoW scheme. It would perhaps be preferable to try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to minimize the advantage of adversaries with GPUs etc.? Are there any good such schemes? Also services should definitely be able to configure the difficulty of the PoW, and IMO this should again happen through the descriptor. That PoW scheme was just a simple example. We should find the right choice. Something hard to find but easy to check. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
George Kadianakis:
>> 2.Client computes POW.
>> Do{
>> Generates random 8 bytes key (ClientKey).
>> Generates hash(sha512/256 or sha3??) of
>> hash(IPKey + ClientKey)
>> } while (hash does not start with "abcde")
>>
>
> That looks like a naive PoW scheme. It would perhaps be preferable to
> try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to
> minimize the advantage of adversaries with GPUs etc.? Are there any
> good such schemes?
It may be worth looking at Argon2 [1] which is designed to maximize the
cost of password cracking on ASICs based on memory-hard functions.
A different approach is the input-dependent use of several different
hash functions (cf. e.g. [2]).
[1] https://www.cryptolux.org/images/0/0d/Argon2.pdf
[2] https://www.pascalcoin.org/storage/whitepapers/RandomHash_Whitepaper.pdf
> Also services should definitely be able to configure the difficulty of
> the PoW, and IMO this should again happen through the descriptor.
yes
signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal for PoW DoS defenses during introduction (was Re: Proposal 305: ESTABLISH_INTRO Cell DoS Defense Extension)
juanjo writes:
> Hello, this is my view of things, please be gentle as this is my first
> proposal draft :)
>
Hello,
thanks for working on this. IMO any proof-of-work introduction proposal
can be seen as orthogonal to David's prop305 which is a rate-limiting
proposal (even tho it's not named as such) and hence deserves its own
thread.
> _ADAPTIVE POW PROPOSAL:_
>
> Client sends the INTRODUCE1 as normal.
>
> Introduction Point checks the Current Requests Rate and checks the DoS
> settings.
>
> -DoS check is OK: send INTRODUCE2 to Hidden Service etc...
>
So far so good (even tho this is not our usual proposal format).
> -DoS settings/rate limit reached: then
>
> 1.Introduction Point generates a random 8 bytes key (IPKey) and
> associates it with the client circuit. Then send INTRODUCE_POW to the
> Client with the IPKey.
Is this a new cell? What's the format? Are these really keys or are they
just nonces?
IMO we should not do this through a new cell because that increases the
round-trip by one. Instead we should just embed the PoW parameters in
the onion service descriptor and clients find them there.
> 2.Client computes POW.
> Do{
> Generates random 8 bytes key (ClientKey).
> Generates hash(sha512/256 or sha3??) of
> hash(IPKey + ClientKey)
> } while (hash does not start with "abcde")
>
That looks like a naive PoW scheme. It would perhaps be preferable to
try to find a GPU/ASIC-resistant or memory-hard PoW scheme here, to
minimize the advantage of adversaries with GPUs etc.? Are there any
good such schemes?
Also services should definitely be able to configure the difficulty of
the PoW, and IMO this should again happen through the descriptor.
> 3. Client sends INTRODUCE_POWR to the I.P. with the generated POW
> and the ClientKey.
IMO this should happen as part of the INTRODUCE1 cell.
> 4. I.P. checks the POW:
>
> -POW is correct: send INTRODUCE2 to HS.
> -POW is not correct: send INTRODUCE_POW_ERROR to client with
> new IPKey.
>
> *I say 8 bytes for the Keys just for example.
>
> PROS AND CONS, who needs to update Tor version?:
> --
>
> Only rate limit: Introduction Point and Hidden Service. No breakage.
>
> POW: Client, Introduction Point and Hidden Service. POW will break
> compatibility with other v3 Hidden Services clients, if we implement a
> way to bypass POW for old clients then this feature won't work as intended.
>
> A forgotten guy here: Authenticated Rends cell: where we make sure the
> Client established a connection to the Rend Point before requesting the
> INTRODUCE1.
>
Yep, that's yet another proposal (ticket #25066).
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
