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
| ||
|
Date: Tue, 7 Apr 2015 00:44:56 +0300 From: Solar Designer <solar@...nwall.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] PHC: survey and benchmarks Steve - I think you haven't yet posted a clarification on my concerns below, yet now this table made its way into Milan's revised report. Please clarify what exactly you meant by "t_cost for 2x". Thanks! On Wed, Apr 01, 2015 at 04:33:54PM +0300, Solar Designer wrote: > Steve, > > On Mon, Mar 23, 2015 at 09:33:28PM -0500, Steve Thomas wrote: > > Name | t_cost for 2x | t_cost for 3x | t_cost for 4x | t_cost for 5x > > -----------+---------------+---------------+---------------+--------------- > > Argon | 2 | 3 | 4 | 5 > > battcrypt | 0 | 1 | 3 | - > > Catena | 2 | 3 | 4 | 5 > > Lyra2 | 2 | 3 | 4 | 5 > > POMELO | 1 | - | 2 | - > > Pufferfish | - | 0 | - | 1 > > yescrypt | 3 | 4 | 5 | 6 > > For yescrypt it's t = 2 to have it perform 2x the number of read-writes > compared to the total number of blocks. t = 0 means 4/3, t = 1 means > 5/3, and t = 2 means 2. Then it's just whole numbers. > > So if I understood you right, all of the numbers for yescrypt in the > table above should be decreased by 1. > > ... or are you only counting memory accesses starting with the point > where the memory is filled, and not counting the initial accesses > during memory filling (which often involves reads of previously-written > blocks, and thus contributes to the attacker's area-time product too)? > If so, your table is correct (for yescrypt; I didn't verify the rest). > > Alexander
Powered by blists - more mailing lists