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
Description: MS-Excel 2007 spreadsheet
> 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
