
Password Hashing Competition - LaSombra
https://password-hashing.net/report1.html
======
jszymborski
I'm no cryptoexpert but I was under the impression that slow password hashes
were best, as they are harder to generate rainbow tables for and brute force
the algorithm. Many of these algos are put aside for being too slow or praised
for speed, and CPU/GPU optimization seems to be a big goal.

~~~
warbiscuit
It's not necessarily "slow is best", but rather minimizing the ratio between
how fast your production server can calculate them multiple hashes while under
load, vs how fast your attacker can crack them on dedicated hardware.

Which, for example, is why something based on SHA3 is bad, because your
typical server is just going to be doing SHA3 hashes via CPU. Except SHA3 was
chosen to be ASIC-friendly, so your attacker will be able to calculate SHA3
faster than you. As long as the attacker has no faster calculation method than
the one you're using, the absolute speed doesn't matter. This is why scrypt,
bcrypt (and to a lesser extent pbkdf2-hmac-sha256) are doing well, because
running them on GPU or ASIC isn't meaningfully faster than the CPU
implementation the defender is using.

All that's left at that point is making it as expensive as possible for them
to parallelize their attack. Which is what scrypt and other things attempt to
do -- require as many non-CPU resources (memory, hd space, etc) so that the
attacker's parallelization cost is also maximized.

(Personally, I've been playing around with the idea of incorporating random
accesses to a 2-tb file of random data, so that the attacker would have a HUGE
amount of data to steal before my hashes would work. And they'd have to
establish shared access to all the CPUs/etc they're attacking with)

~~~
floody-berry
yescrypt has ROM capabilities [1], which function like your large file idea.

[1] [https://password-hashing.net/wiki/doku.php/yescrypt#read-
onl...](https://password-hashing.net/wiki/doku.php/yescrypt#read-
only_lookup_table_rom)

~~~
warbiscuit
Ooh, that looks interesting ... and not just for ROM feature. They've packed a
TON of things into there. Even SCRAM support!

I'm really intrigued by one of the planned features... "Hash upgrades to
higher cost settings without knowledge of passwords". I can think of a way to
implement that alone, but to pack that all in with those other features will
be really impressive. And would be a huge boon to systems w/ infrequently
logging-in users.

~~~
solardiz
"Hash upgrades" have been added with the just-published v1 of the yescrypt
submission to PHC. There is not yet an implementation of an "upgrade this
hash" function (also, hash encoding needs to be finalized, including encoding
of the upgrade count parameter), but now it's a matter of writing this
additional code outside of the actual password hashing code (already capable
of computing possibly-upgraded hashes).

Unfortunately, with memory-hard schemes such upgrades involve an efficiency
loss in terms of normalized area-time, and there's a tradeoff between
granularity of upgrades and efficiency. For Catena (another PHC finalist that
supports these), the time granularity is 2x to 3x, with efficiency down to
33.3%+ of non-upgraded hashes (after many upgrades). For yescrypt, it's 4x to
5x granularity and 60%+ efficiency, respectively. (I felt that 33.3%+ is just
not good enough - in my opinion, it's usually better to postpone the upgrade
until 60%+ can be achieved rather than upgrade early and prevent it from ever
being achieved. The next easy step would be 77.7%+, but the granularity would
be too high.)

At the same time, support for ROM access frequency tuning (and thus for ROM-
on-SSD, as opposed to ROM-in-RAM) has been dropped from yescrypt for now. The
rationale is that builtin ROM-on-SSD didn't make enough sense without also
having a ROM-in-RAM (in use cases for the former, the latter would also be
easily affordable, including complexity wise, and would provide significant
extra defense), and supporting two ROMs at once would be further beyond the
comfort level for complexity of a hashing scheme in PHC (yescrypt is already
somewhat beyond the comfort level). Support for two ROMs along with access
frequency tuning might be re-added in an extended revision of yescrypt for
specialized use cases at a later time, but this will be outside of PHC.

------
yowmamasita
Are there any pure Python implementation of these algorithms? I am looking for
something that would work with Google App Engine.

------
cmiller1
I wonder how these compare with bcrypt and scrypt. Anyone have any insight?

~~~
solardiz
Differently! The goal of PHC is to improve upon the current state-of-the-art,
which includes bcrypt and scrypt, but there are many tradeoffs involved. A
scheme that is better in one aspect might be worse (or just different) in
another.

These finalists try to improve upon scrypt (increase attack/defense cost ratio
or/and avoid cache-timing side-channels while building upon ideas from scrypt
and more): Argon, Catena, Lyra2, yescrypt, and maybe POMELO. Ditto for some
non-finalists: Gambit, RIG, TwoCats. (Arguably some other non-finalists fall
in this category as well.)

These finalists include bcrypt-like components or properties while being
scalable (to a varying extent) to larger than bcrypt's memory usage:
battcrypt, POMELO, Pufferfish, yescrypt. And a non-finalist: TwoCats. Unlike
bcrypt itself, battcrypt is likely to be implementable in scripting languages
that offer native Blowfish.

These finalists are totally different from bcrypt and scrypt, not trying to
improve upon them nor even be on par with them: Makwa and Parallel. They are
for different applications than bcrypt and scrypt. Parallel can be said to try
to improve upon PBKDF2, though.

As to more specific comparisons, with benchmarks and cost estimates for
various settings on various types of hardware, this goes beyond a comment
reply like this (or I'd need to focus on one PHC candidate, like mine, which
would be unfair). It is a topic for the PHC discussions list and for materials
included with each PHC candidate (some do include various numbers or/and
claims to this extent).

