Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://www.password-hashing.net/report-finalists.html below:

Password Hashing Competition

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.

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.

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

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

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

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

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

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

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

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

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

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.

• 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

• Withdrawn

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

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

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

• Too slow for its memory usage

• Withdrawn

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

• 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

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

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

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

• Fails basic statistical tests

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

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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4