Password Hashing Competition

PHC call for submissions

The Password Hashing Competition (PHC) organizers solicit proposals from any interested party for candidate password hashing schemes, to be considered for inclusion in a portfolio of schemes suitable for widespread adoption, and covering a broad range of applications.

Submissions are due by March 31, 2014. All submissions received that comply with the submission requirements below will be made available on the website of the project, https://password-hashing.net.

Technical guidelines

The submitted password hashing scheme should take as input at least

A password of any length between 0 and 128 bytes (regardless of the encoding).
A salt of 16 bytes.
One or more cost parameters, to tune time and/or space usage.

The scheme should be able to produce (but is not limited to) 32-byte outputs. If multiple output lengths are supported, the output length should be a parameter of the scheme. Similarly, if multiple salt lengths are supported, the salt length should be a parameter. Passwords longer than 128 bytes may be supported, but that is not mandatory.
Other optional inputs include local parameters such as a personalization string, a secret key, or any application-specific parameter.

Submissions will be evaluated according the following criteria:

Security

Cryptographic security: the function should behave as a random function (random-looking output, one-way, collision resistant, immune to length extension, etc.).
Speed-up or other efficiency improvement (e.g., in terms of memory usage per password tested) of cracking-optimized implementations (checking multiple sets of inputs in parallel, and doing so in a CPU's native code) compared to implementations intended for password validation should be minimal.
Speed-up or other efficiency improvement (e.g., in terms of area-time product per password tested) of cracking-optimized ASIC, FPGA, and GPU implementations (checking multiple sets of inputs in parallel) compared to CPU implementations intended for password validation should be minimal.
Resilience to side-channel attacks (timing attacks, leakages, etc.). In particular, information should not leak on a password's length.

Simplicity

Overall clarity of the scheme (design symmetries, modularity, etc.).
Ease of implementation (coding, testing, debugging, integration).
Use of other primitives or constructions internally (the fewer, the better).

Functionality

Effectiveness of the cost parameter (e.g. can the time and space expected requirements be bypassed?).
Ability to transform an existing hash to a different cost setting without knowledge of the password.

Submitters are encouraged to propose innovative constructions and methods for protecting passwords against attackers that have fully or partially compromised a server storing password hashes. For example, one may design a scheme that is slow to evaluate except on a server given some server-specific shortcut.
Submissions may also be specific to a specific application, such as mobile devices (e.g. to protect PINs), key derivation (e.g. for full-disk encryption), scripting languages (as opposed to native implementations), etc.

Submission requirements

Submissions should be sent to [email protected] on or before March 31, 2014 as a compressed archive (tar.bz2, tar.gz, or zip). All submissions will be acknowledged.

The following are to be provided with any submission:

Cover sheet

Name of the submitted scheme (preferably a valid C identifier).
Name and email address of the submitter(s).

Specification

Complete and unambiguous description of the scheme; however if the scheme reuses an existing primitive, this primitive need not be described (for example, if the scheme uses AES, it is not necessary to copy the specification of AES).
Statement that there are no deliberately hidden weaknesses (backdoor, etc.); any sign of such ill intent will be grounds for disqualification.

Initial security analysis

Discussion of the security claims and usage constraints of the proposed algorithm: For which usage scenarios do the designers claim their algorithm secure, and when should it not be used?
Discussion of the security of the algorithm, and its dependence on the security of cryptographic primitives used by the algorithm.

Efficiency analysis

Discussion of the performance of the scheme on the target platforms (that is, mainstream software): expected speed of an optimized implementation, ability to exploit modern CPUs features (SIMD or multicore), etc.
Discussion of the performance of the algorithm on platforms that may be used for high-speed password cracking (ASIC, FPGAs, GPUs); if possible, an argument why password-cracking on those platforms is not quite cost-effective.

Code

Reference implementation in portable C(++) with necessary build instructions (e.g. a Makefile). Using C++ internally is allowed, but the program should provide an external C API. OpenSSL's libcrypto may be used (e.g. for AES, SHA-256). The reference implementation should aim at simplicity and readability, rather than at performance.
The API should include, but may not be limited to, a function with the following prototype:
int PHS(void *out, size_t outlen, const void *in, size_t inlen, const void *salt, size_t saltlen, unsigned int t_cost, unsigned int m_cost);
The t_cost and m_cost arguments are intended to parameterize time and memory usage, respectively, however this is not a strict requirement (only one parameter may be effective, m_cost might affect time, etc.).
Comprehensive set of test vectors (preferably including all byte values in the 0 to 255 range for both the password and the salt inputs).
Optionally, implementations in other languages or specific to a given CPU/GPU, microarchitecture, etc.

Intellectual property statement

Statement that the scheme is and will remain available worldwide on a royalty free basis, and that the designer is unaware of any patent or patent application that covers the use or implementation of the submitted algorithm.