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.
The submitted password hashing scheme should take as input at least
The scheme should be able to produce (but is not limited to) 32-byte
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
A password of any length between 0 and 128 bytes (regardless of the
A salt of 16 bytes.
One or more cost parameters, to tune time and/or space usage.
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:
Cryptographic security: the function should behave as a random function
(random-looking output, one-way, collision resistant, immune to length
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.
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).
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.
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.
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),
Submissions should be sent to firstname.lastname@example.org
on or before March 31, 2014 as a compressed archive (tar.bz2, tar.gz,
All submissions will be acknowledged.
The following are to be provided with any submission:
Name of the submitted scheme (preferably a valid C identifier).
Name and email address of the submitter(s).
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
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.
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
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
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 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,
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.