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