I think this data proves the idea that the difference between
computation power of different clients is significant and
no single puzzle difficulty level would be reasonable for all.
I think we should proceed with the proposal that
client is allowed to return less zero bits than requested.
And in this case we may go further.
The server may even not indicate to the client
how many zero bits it wants to get. The server
could just give the puzzle to the client and
the client would return the best solution that it can
get for a reasonable (from client's point of view) time.
Some clients would be able to get more zero bits, some less.
Then the server would sort all the requests, as described
in Tero's e-mail and serve them accordingly.
Valery.
----- Original Message -----
From: "Yoav Nir" <ynir.i...@gmail.com>
To: "Yaron Sheffer" <yaronf.i...@gmail.com>
Cc: "Valery Smyslov" <sva...@gmail.com>; "IPsecME WG" <ipsec@ietf.org>
Sent: Wednesday, February 04, 2015 8:06 PM
Subject: Re: [IPsec] DDoS puzzle: PRF vs Hash
OK, now I’ve got a chance to test on an ARM appliance (similar in power to a
2-3 year old phone, I think.
Again these are single-core results, but there’s an extra bit of badness
here in that this is a C implementation of SHA256. We could probably gain
around 2 extra bits with an assembly-language implementation. As it is, it’s
about 4 bits behind the Intel i5.
Yoav
--------------------------------------------------------------------------------
On Feb 2, 2015, at 8:31 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
The three-sigma rule applies even with a non-normal distribution.
Anyway, I tried the 64-key sample. Results are slightly better.
Yoav
<data64.xlsx>
On Feb 1, 2015, at 7:36 PM, Yaron Sheffer <yaronf.i...@gmail.com> wrote:
Hi Yoav,
This is good, but I'm not sure if it's good enough. The ratio between min
and max (which I trust more than the "mean +/- 3s" rule, because this is
not a normal distribution) is consistently around 4. So if you have to
design your timeouts on a particular machine, you would still have a lot
of uncertainty. For comparison, could you try again with 64 replacing the
16 tries, and with lower bit lengths?
Thanks,
Yaron
On 02/01/2015 11:46 AM, Yoav Nir wrote:
And now it’s really attached.
On Feb 1, 2015, at 11:45 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
On Jan 31, 2015, at 12:35 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
On Jan 30, 2015, at 3:37 PM, Yaron Sheffer <yaronf.i...@gmail.com>
wrote:
What I would suggest is: we give the client a single puzzle, and ask
it to return 16 different solutions. Indeed each puzzle then should
be 16X easier. The nice thing is, the server should only check *one*
of them, at random. The client would still need to solve all of them
because it doesn't want to risk the exchange being rejected because
some solutions are invalid (the game theory is probably more complex
than that, but I think what I'm saying is still close to the truth).
So: the client does the same amount of work, the server does the same
amount of work, but the client run-time is still much more
deterministic.
<snip />
Note that these are still single core results, and most laptops can do
twice or four times as much. Now, I know that what I SHOULD be doing
is to randomly generate 100 “cookies” and then calculate the times for
different bit lengths for each of them, and then calculate mean and
standard deviation. But just by looking, it looks like it’s much
closer to what we want. 16 bits would be a fine puzzle level for my
laptop. No idea about a phone, although I could try to compile this
and run it on an ARM-based appliance, which should match phones.
OK. Now I have done it right. See attached. The data suggests that 15
or 16 bits is the level of puzzle that for this kind of hardware is
challenging but not too onerous. Add another bit if we assume (probably
correctly) that the vast majority of laptops have dual cores at least.
I would like to run a similar test on an ARM processor, though. The
capabilities of phones and tablets are all over the place, what with
different versions of ARM processors and devices having anything from
dual to octo-core, but it would be nice to get ballpark figures.
Yoav
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
