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: <20150413151121.GA29402@openwall.com> Date: Mon, 13 Apr 2015 18:11:21 +0300 From: Solar Designer <solar@...nwall.com> To: discussions@...sword-hashing.net Subject: winner selection Hi, Similarly to the process the PHC panel used to focus the discussion on finalist selection, we just collected votes/comments for winner selection from PHC panel members. (Not all have provided these, but many did.) JP collected these in private, and made them available to the rest of the panel yesterday. This time, panel members with their own submissions were also asked to vote or comment, including on their own submissions, but their votes or comments need to be made public. For the sake of transparency, as well as to have any possible misunderstanding on my part detected sooner rather than later, I am posting my comments in here right away. (I did not submit any numeric votes.) I initially wrote these on March 29, and revised on April 10 shortly before my more thorough review of Pufferfish. Please note that other panel members' PHC winner preferences may and often do differ. We have not arrived at a consensus yet. Not even on whether there should be one or multiple winners. --- Argon - a non-winner: too TMTO-obsessed and thus slow, likely at the expense of security against actual attacks. (As a side note, this is something that has been addressed in Argon2, although there's another issue in Argon2: currently excessive parallelism.) The original Argon submission, while also being TMTO-obsessed, had the advantage of being simple and maybe NIST(?) standardization friendly, for its use of AES only. The tweaked Argon, while addressing some real limitations and drawbacks of the original submission, has lost much of its simplicity. It now depends not only on AES, but also on Blake2b. If it addressed even more of the drawbacks, it would still be within consideration as a potential winner for me, but it did not. (Argon2 did, and it dropped the dependency on AES, but at the same time it has the issue of currently excessive parallelism, so I wouldn't recommend it for that reason. And this is non-PHC anyway.) Very good contributions by the Argon team to TMTO analysis of other PHC candidates (and beyond PHC), though. Definitely deserves recognition. battcrypt - likely winner. battcrypt wins over Pufferfish at sizes over a few MB, per Milan's benchmarks. Also has the advantage of using only standard crypto primitives - SHA-512 and Blowfish - vs. Pufferfish's SHA-512 and a Blowfish-alike. This may provide greater confidence, although on the other hand there are voices saying that Blowfish is dated and "1990s crypto" (but so what?) More importantly, use of standard Blowfish makes battcrypt efficiently implementable in scripting languages, as evidenced by the included implementation in PHP. A lengthy comment in there appears to claim there's only a 2x reduction in Blowfish blocks processed per second compared to bcrypt. We'll need to verify this. (And probably the reduction is caused by current PHP's implementation of Blowfish being suboptimal, rather than by battcrypt's or PHP's overhead.) If true, and I see no reason why it wouldn't be, battcrypt is no more than 2x worse than bcrypt at anti-GPU. That's very good for something implementable in a scripting language. We'll need to verify how it actually behaves in GPU attacks. Catena - likely winner, especially its Catena-Dragonfly flavor, which is actually fast (unlike other 3 default instantiations of Catena). The Catena v3 specification document suggests that Catena-Butterfly be used for low memory scenarios, because it provides extra TMTO resistance "for free" (if the defender couldn't have used more memory anyway). This makes sense. What use are the -Full instantiations, though? Paranoia? Maybe we should verify that there are entropy bypasses via the full round count H in Flap? At first glance, I'm not sure if there are. If not, maybe that should be added (if we introduce a panel proposed tweaks phase in PHC). Lyra2, POMELO, or/and yescrypt - select one or several of these as winner(s). I've already commented on Lyra2 vs. yescrypt on the public list, in many separate postings. I may provide a summary comparison between these two or three, if desired. POMELO v2 is now comparably fast, and it differs in that it's much simpler and is self-contained. The same may be viewed as a drawback, as confidence in its cryptographic security might be lower. yescrypt's low memory threshold for GPU resistance is probably lower than for the other two, but this has yet to be confirmed. It is possible that on current GPU devices Lyra2 and/or POMELO perform poorly enough even at low memory, but yescrypt's design and tuning provide greater confidence of being no worse than bcrypt. In some initial tests, POMELO is slow to attack on GPUs (slower than on CPUs) even at low memory. Makwa - likely select as a winner, but may need more pairs of eyes first, who would confirm they have actually reviewed Makwa. I think Steve did? Anyone else? I didn't review it, and I think we have panel members who are more qualified to review it. Makwa is a likely winner because it provides a unique feature with specific use cases for it, it looks good at first glance (but indeed that's not a proper review), and it comes from a particularly careful submitter. Parallel - I am not interested in this one at this time, but I agree we needed a scheme like this in PHC. If we're almost sure it will be standardized e.g. by NIST, and no other PHC winner would be, then that's a reason to select it as a winner. Will it mostly replace PBKDF2 even if not standardized by any established organization? Will being a PHC winner be good enough for that? Maybe. Is Parallel's simplicity alone worth making it a winner, for those users who would not implement anything more complex properly or at all? We need to discuss this. Pufferfish - might be more suitable than battcrypt and possibly than POMELO in a rather narrow yet important range of m_cost, perhaps from 8 KB to ~1 MB. Is this worth selecting it as a winner? I'm not sure. I think it loses to battcrypt or/and to POMELO at larger sizes. Also, even if POMELO loses to Pufferfish at anti-GPU at low memory currently (although it appears to be OK so far), I guess it may be tweaked not to lose during my proposed standardization and tweaking-by-panel phase. OTOH, Pufferfish could also use some minor improvements. This most likely gives us between 3 (Catena, Lyra2 or POMELO or yescrypt, Makwa) and 7 winners (s/or/and/ and add battcrypt and Pufferfish). Argon and Parallel are not on my preferred list of winners, but having Parallel would make (more) sense to me. Almost all finalists are in need of having their submission packages improved before we possibly encourage their use. For many, it's the big-endian support. For yescrypt, the specification document needs significant improvements. I wanted to avoid even mentioning yescrypt here, but I could not because then I'd have to say that Lyra2 and/or POMELO should or should not be a winner unconditionally, which isn't my true opinion. --- Alexander
Powered by blists - more mailing lists