lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <CALW8-7+idF8n1HQfHAcbU53JfBdh2WSwd0ZV7DWQ3zhaeivyDA@mail.gmail.com> Date: Wed, 1 Apr 2015 12:38:25 +0300 From: Dmitry Khovratovich <khovratovich@...il.com> To: "discussions@...sword-hashing.net" <discussions@...sword-hashing.net> Subject: Re: [PHC] OMG we have benchmarks I apologize, I meant "some other schemes". Dmitry On Wed, Apr 1, 2015 at 12:37 PM, Hongjun Wu <wuhongjun@...il.com> wrote: >>> Argon and Argon2 do not have other parameters that affect the >>> performance crucially (apart from multithreading). However, the other >>> schemes do, and they must be listed (number of rounds in the internal >>> function, specific flags, etc.). > > ....... I think there is some typo in the message above. POMELO is not one > of "the other schemes". > > POMELO does not have other parameters that affect the performance. More > specifically, the performance of POMELO is only affected by m_cost and > t_cost (so there is no multiple algorithms, no multi-threading, no number > of rounds, no specific flags, etc ...) > > Best Regards, > hongjun > > > > On Wed, Apr 1, 2015 at 5:24 PM, Dmitry Khovratovich <khovratovich@...il.com> > wrote: >> >> Great work! I think it is what we need. >> >> Just there must be proper parameter choice. >> >> For Argon2d the memory is looped over <t_cost> times, and t_cost=1 is >> minimally secure and recommended. >> >> For Argon2i the memory is looped over <t_cost> times, and t_cost=3 is >> minimally secure and recommended. >> >> For Argon the memory is looped over <2*t_cost+1> times, and t_cost=3 >> is minimally secure and recommended. >> >> Argon and Argon2 do not have other parameters that affect the >> performance crucially (apart from multithreading). However, the other >> schemes do, and they must be listed (number of rounds in the internal >> function, specific flags, etc.). For fair benchmark comparison, the >> designers must choose some recommended set of parameters, explicitly >> claim its security, and yield it for measurement. >> >> Dmitry >> >> On Wed, Apr 1, 2015 at 12:01 PM, Milan Broz <gmazyland@...il.com> wrote: >> > On 04/01/2015 10:45 AM, Solar Designer wrote: >> >> On Wed, Apr 01, 2015 at 03:02:07AM -0500, Steve Thomas wrote: >> >>> >> >>> https://raw.githubusercontent.com/mbroz/PHCtest/master/output/round2_Lenovo_X230_i5_16G/mc_cost_2/memory_time_round.png >> >>> >> >>> Note I believe there might be a problem with some of it: battcrypt on >> >>> 5x and >> >>> POMELO on 3x and 5x. Since those algorithms don't have t_costs for >> >>> those and I >> >>> think they are run at lower settings. >> >>> >> >>> But ignoring that these are the best benchmarks I've seen since >> >>> they're >> >>> normalized for rounds across memory and time vs memory (instead of >> >>> having t_cost >> >>> or m_cost as an axis). >> >> >> >> Cool! Why are these for t_cost from 2 to 5, though? Where's t_cost 0 >> >> and 1? I think only behavior with the lowest supported t_cost matters >> >> for selection of a scheme, whereas exactly how higher t_cost affects >> >> the >> >> behavior is merely additional information to be used for fine-tuning. >> >> >> >> Also, are the Lyra2 results included here for 1 or 2 threads? >> >> >> >> I assume the rest are for 1 thread? >> > >> > Well, it was just test run, but once it is already here: >> > >> > https://raw.githubusercontent.com/mbroz/PHCtest/master/output/round2_Lenovo_X230_i5_16G/mc_cost_2/memory_time_round.png >> > >> > - I fixed point colors, so it should now match all 4 versions. >> > >> > - Yescrypt has in 3 x round two more points (2GiB) - just typo in >> > script. >> > (I'll run all algs up to 8GiB but it will take long time -> later) >> > >> > - Lyra2 should be for 1 thread (-DnPARALLEL=1) >> > >> > - Parameters are according to Steve's table >> > http://article.gmane.org/gmane.comp.security.phc/2550 >> > (also in https://github.com/mbroz/PHCtest/issues/1 ) >> > >> > - the low memory setting is "unstable" because of RUSAGE measurement: >> > Real memory us is simple difference of getrusage(RUSAGE_SELF, ...) >> > before and after run (well, here maximum of three runs). >> > >> > So for small memory allocations it can be even zero (because that >> > process >> > already have some memory pre-allocated). My intention was to show that >> > it >> > really have expected peak there. >> > (So it will not match your calculation exactly but it must be very >> > close.) >> > >> > Graph for t_min is here (but is somehow strange) >> > >> > https://raw.githubusercontent.com/mbroz/PHCtest/master/output/round2_Lenovo_X230_i5_16G/m_cost/memory_time.png >> > >> > Milan >> >> >> >> -- >> Best regards, >> Dmitry Khovratovich > > -- Best regards, Dmitry Khovratovich
Powered by blists - more mailing lists