PHC status report

First published on February 3, 2015, by the PHC panel

The Password Hashing Competition (PHC) is a project aiming to identify new password hashing schemes in order to improve on the state-of-the-art and to encourage the use of strong password protection.  In March 2014, PHC received 24 complete submissions. Based on the discussions on the public and private mailing lists, finalists of the competition are announced on December 8, 2014.

This report provides rationale on the selection of the nine PHC finalists, which are Argon, battcrypt, Catena, Lyra2, Makwa, Parallel, POMELO, Pufferfish, yescrypt.

Selection criteria including, in no particular order:

• Defense against GPU/FPGA/ASIC attackers
• Defense against time-memory tradeoffs
• Defense against side-channel leaks
• Defense against cryptanalytic attacks
• Elegance and simplicity of design
• Quality of the documentation
• Quality of the reference implementation
• General soundness and simplicity of the algorithm
• Originality and innovation

We attempted to include algorithms relevant for most applications of a password hashing scheme, from web service authentication to client login or key derivation. We also believed that having diversity in the finalists is beneficial, therefore selected algorithms of different types and suitable for different applications.

Below we provide comments about each of the 24 submissions, to help understand our decisions. Due to limited time and resources, we succinctly report the main reasons that motivated our selection or non-selection as a finalist.

We thank all submitters for their contribution. Comments and questions may be sent to the public PHC mailing list or to [email protected].

It is planned that the PHC winner(s) be announced in Q2 2015.

Finalists

Below we list specific properties that motivated our selection of the finalists. This is not to say the finalists are free of drawbacks (we are aware of many) or defects. It's just that in this brief report we list some of what motivated our choice in favor of the finalists, rather than against.

Argon

• Thorough security analysis, especially against TMTO
• Uses only AES as external primitive, often available as CPU instructions

battcrypt

• Simple and minimalistic design and implementation
• Optimized for PHP, as it includes a Blowfish implementation

Catena

• Well-motivated design, convincing theoretical framework
• Well-understood side-channel and TMTO resistance

Lyra2

• Elegant sponge-based design, with a single external primitive
• Good security analysis

Makwa

• Unique design supporting delegation, suited only for specific applications
• Thorough analysis and documentation, good quality code

Parallel

• Minimalistic and compact design, addressing low-memory applications
• Original distinction of sequential vs. parallel cost

POMELO

• No external primitive required, partial cache-timing mitigation
• Polished documentation and (succinct) code

Pufferfish

• Leverages bcrypt's understanding and GPU resistance
• Enhanced bcrypt with 64-bit optimization and support for higher memory

yescrypt

• Leverages scrypt's understanding and modularity
• Well-understood performance ratio, simplification potential

Non-finalists

Given that diversity was among our criteria for selection of finalists, non-selection of a submission does not necessarily imply that we found the submission less suitable than all of those we selected as finalists—in some cases, the non-finalist submission merely received considerably less support by the panel than other submissions that we felt were competing in the same category (targeting the same use cases and/or offering the same kind of defenses). Without what we deemed a more suitable submission in a (loosely defined) category, some of these non-finalist submissions could have been selected. Besides, a number of non-finalists contributed original or interesting ideas, and this contributed to our understanding of what constitutes a password hashing scheme suited for practical applications. That said, we actually found many non-finalists less mature, less analyzed, and generally less understood than most of the finalists.

Below we point out specific properties or defects that motivated our choice. This is not to say the non-finalists lack advantages (we are aware of many). It's just that in this brief report we list some of what motivated our choice against the non-finalists, rather than in favor.

AntCrypt

• Data-dependent branching is a controversial area not sufficiently explored in time for this competition, hence current design was deemed unlikely to maximize benefits vs. risks
• Floating-point arithmetic complicates reproducibility and portability

Catfish

• Withdrawn

Centrifuge

• Too slow for its memory usage (byte-grained random memory accesses)

EARWORM

• Relies solely on ROM-hardness whereas better understood defenses are also affordable by its target applications
• Uses multiple external primitives, not second-preimage resistant

Gambit

• Similar to Catena, but a less mature design and potentially worse ASIC resistance (due to the use of Keccak)

Lanarea

• Too slow for its memory usage

M3lcrypt

• Withdrawn

MCS_PHS

• Similar to PBKDF2, without significant improvement
• Unclear security of the underlying hash, from earlier versions' breaks

OmegaCrypt

• Same concern about data-dependent branching as with AntCrypt, and partially predictable branches and memory addresses (unlike claimed)
• Lack of convincing security or performance analysis

PolyPassHash

• A protocol to recover a symmetric key used to encrypt passwords, not a password hashing scheme, too far from what PHC is expecting

RIG

• Similar to Catena, but received less attention (cf. bugs found in the v1 specification and code)

Schvrch

• Cryptographically weak
• ASIC-friendly, total cost = time + memory

Tortuga

• Fails basic statistical tests

TwoCats

• Interesting mix of ideas, but less understood design than other candidates in the same space

Yarn

• Not as mature and finely-tuned design as other candidates in its category