On Tue, Sep 22, 2020 at 2:10 PM George Kadianakis wrote:
>
> if you have a GPU-enabled box, so that we can get some benchmarks
> from GPUs as well
>
Someone would have to write a GPU benchmark for that. My code is CPU-only.
>
> tevador do you have the graphing code somewhere so that I can run
On 9/22/20 07:10, George Kadianakis wrote:
> George Kadianakis writes:
>
>> tevador writes:
>>
>>> Hi all,
>>>
> Hello,
>
> I have pushed another update to the PoW proposal here:
> https://github.com/asn-d6/torspec/tree/pow-over-intro
> I also (finally) merged it upstream to torspec as proposa
George Kadianakis writes:
> tevador writes:
>
>> Hi all,
>>
Hello,
I have pushed another update to the PoW proposal here:
https://github.com/asn-d6/torspec/tree/pow-over-intro
I also (finally) merged it upstream to torspec as proposal #327:
https://github.com/torproject/torspec/blob/maste
tevador writes:
> Hi all,
>
Hello tevador,
thanks so much for your work here and for the great simulation. Also for
the hybrid attack which was definitely missing from the puzzle.
I've been working on a further revision of the proposal based on your
comments. I have just one small question I w
On 22 Jun (17:52:44), George Kadianakis wrote:
> Hello there,
>
> here is another round of PoW revisions:
> https://github.com/asn-d6/torspec/tree/pow-over-intro
> I'm inlining the full proposal in the end of this email.
>
> Here is a changelog:
> - Actually used tevador's EquiX scheme as ou
Hi all,
On Mon, Jun 22, 2020 at 4:52 PM George Kadianakis wrote:
> Also, tevador let me know if you'd like me to add you as a co-author on the
> proposal based on all your great feedback so far.
Thanks for the update. Yes, you can add me as a co-author.
> During our performance measurements in
Hello, list !
Some ideas about this proposal, it's a little bit surface ideas, cause
I'm not currently digging deep into the internals of Tor-core.
There's user division on different classes there ("The standard web
user", "The motivated user", "The mobile user").
I would add "Registered u
Hello there,
here is another round of PoW revisions:
https://github.com/asn-d6/torspec/tree/pow-over-intro
I'm inlining the full proposal in the end of this email.
Here is a changelog:
- Actually used tevador's EquiX scheme as our PoW scheme for now. This is still
tentative, but I needed s
Hi George,
Thanks for the update.
On Wed, Jun 10, 2020 at 2:05 PM George Kadianakis wrote:
>
> Tevador, thanks a lot for your tailored work on equix. This is fantastic.
> I have a question that I don't see addressed in your very well written
> README. In your initial email, we discuss how
Hello,
after reading all the excellent feedback on this thread, I did another
revision on this proposal:
https://github.com/asn-d6/torspec/tree/pow-over-intro
I'm inlining the full proposal in the end of this email.
Here is a changelog:
- Improve attack vector section
- Shrink nonce size on cel
On Mon, Jun 8, 2020 at 3:09 AM wrote:
>
> It looks like all the 40320 permutations of the 16-bit words in S are
> equix solutions. Are steps 3 to 5 supposed to be repeated for all the
> permutations?
>
Each unique S provides only one attempt. The indices in S must be
ordered in a certain way, ot
> The client's algorithm:
> Input: C
>
> 1. Select N, E
>
> 2. Calculate S = equix_solve(C || N || E)
>
> 3. Calculate R = blake2b(C || N || E || S)
>
> 4. if R * E > UINT32_MAX, go back to step 1)
>
> 5. Submit C, N, E, S (68 bytes total)
It looks like all the 40320 permutations of the 16-bi
> Sending many requests is not the optimal strategy. One high-effort
> request would have exactly the same chance of being selected as many
> low-effort requests with the same total effort. The difference is that
> with many requests, the client wouldn't know which rendezvous would be
> selected, s
On Sun, Jun 7, 2020 at 8:42 AM wrote:
>
> One way is to include the target effort in requests, and include both
> the server-provided nonce and the target effort as the x in Hx. Then
> only check that the real effort comes out no less than the target
> effort, but use the target effort for everyt
On Mon, May 18, 2020 at 1:01 PM wrote:
>
> When a cell with a small effort in the queue has any chance of getting
> selected, the optimal strategy for a legitimate client would be to
> compute nonces and send as many nonces as possible until it causes
> congestion on his network. Instead when onl
I've been working on a custom PoW algorithm specifically for this
proposal. It is 10x faster to verify than RandomX-Tor and doesn't
require any memory for verification.
Full write-up is here: https://github.com/tevador/equix/blob/master/devlog.md
Especially the comparison table in the Appendix ma
> What is the benefit of this approach rather than discarding low
> priority requests right away in the top-half handler?
>
> Note that a priority queue is typically implemented as a heap, which
> does not support efficient trimming.
Correct me if I'm wrong.
When a cell with a small effort in t
Hi Mike,
My apologies. I thought this later email from 14th April had the
latest version of the proposal:
https://lists.torproject.org/pipermail/tor-dev/2020-April/014225.html
> In short, we let the queue grow at a faster rate than we serve, and we
> trim it occasionally.
What is the benefit of
Hi tevador,
On 5/8/20 2:53 PM, tevador wrote:
> Including the effort has 2 benefits:
>
> 1. In case the Intro Priority Queue is full, the service doesn't need to
>waste time verifying PoW solutions that have effort lower than the last
>element in the queue. While an attacker c
Hi teor,
On Sun, May 10, 2020 at 6:36 AM teor wrote:
>
> There are two possible issues with this design:
>
> Division is expensive on some platforms, including ARM-based devices.
> But there might be a way to calculate an approximate value without division.
> (For example, bit shifts, or multiply
Hi tevador,
> On 9 May 2020, at 06:43, tevador wrote:
>> For our dynamic PoW system to work, we will need to be able to compare PoW
>> tokens with each other. To do so we define a function:
>>unsigned effort(uint8_t *token)
>> which takes as its argument a hash output token, and returns t
On 08 May, 21:53, tevador wrote:
> In particular, the following parameters should be set differently from
> Monero:
>
> RANDOMX_ARGON_SALT = "RandomX-TOR-v1"
>
> The unique RandomX salt means we do not need to use a separate salt as PoW
> input as specified in ยง 3.2.
>
> RANDOMX_ARGON_ITER
Hi all,
I was asked by George to submit my comments about the proposal and to suggest
suitable RandomX parameters for this PoW scheme.
> For our dynamic PoW system to work, we will need to be able to compare PoW
> tokens with each other. To do so we define a function:
> unsigned effort(u
> Hello list,
>
> hope everyone is safe and doing well!
>
> I present you an initial draft of a proposal on PoW-based defences for
> onion services under DoS.
>
Hello again,
many thanks for all the thoughtful feedback!
In the end of this email I inline a new version of the proposal
addressing va
On 06 Apr (17:08:12), Mike Perry wrote:
[snip]
> > I think you'll be bound by the amount of data a connection inbuf can take
> > which has an upper bound of 32 cells each read event.
> >
> > Then tor will have to empty at once the inbuf, queue all INTRODUCE2 cells
> > (at
> > most 32) in that p
Trimming to stuff that I just want to reply to; I otherwise agree.
Note: in a couple places I replied directly to asn's OP, because I
noticed some more questions that I could answer.
On 4/2/20 2:30 PM, David Goulet wrote:
>
> On 02 Apr (18:54:59), George Kadianakis wrote:
>> 2.2.2. Dynamic PoW
>>
Phew! This is lg but excellent! Comments in-line!
On 4/2/20 10:54 AM, George Kadianakis wrote:i
> Hello list,
>
> hope everyone is safe and doing well!
>
> I present you an initial draft of a proposal on PoW-based defences for
> onion services under DoS.
>
> The proposal is not finished
On 02 Apr (18:54:59), George Kadianakis wrote:
> Hello list,
>
> hope everyone is safe and doing well!
>
> I present you an initial draft of a proposal on PoW-based defences for
> onion services under DoS.
>
> The proposal is not finished yet and it needs tuning and fixing. There
> are many plac
Hello list,
hope everyone is safe and doing well!
I present you an initial draft of a proposal on PoW-based defences for
onion services under DoS.
The proposal is not finished yet and it needs tuning and fixing. There
are many places marked with XXX and TODO around the proposal that should
be ad
29 matches
Mail list logo
