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.
> 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
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
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
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
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
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
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
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
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
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
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
12 matches
Mail list logo
