https://github.com/defuse/yescrypt
Non-C Implementations of the yescrypt KDF.
https://github.com/defuse/yescrypt
Last synced: over 1 year ago
JSON representation
Non-C Implementations of the yescrypt KDF.
- Host: GitHub
- URL: https://github.com/defuse/yescrypt
- Owner: defuse
- License: other
- Created: 2015-05-04T20:24:05.000Z (about 11 years ago)
- Default Branch: master
- Last Pushed: 2019-01-16T23:26:13.000Z (over 7 years ago)
- Last Synced: 2025-03-18T08:11:18.804Z (over 1 year ago)
- Language: C
- Size: 663 KB
- Stars: 29
- Watchers: 5
- Forks: 8
- Open Issues: 15
-
Metadata Files:
- Readme: README.md
- License: LICENSE.txt
Awesome Lists containing this project
README
yescrypt
==========
[](https://travis-ci.org/defuse/yescrypt)
This repository holds my implementations of the yescrypt algorithm done for
Google Summer of Code 2015. *WARNING:* This code has not yet been brought up to
date with the latest version of yescrypt, yescrypt 1.0. This is being tracked in
[GitHub Issue #32](https://github.com/defuse/yescrypt/issues/32).
Documentation
---------------
Here are some useful yescrypt and scrypt links:
- [All Password Hashing Competition candidates](https://password-hashing.net/candidates.html)
- [The yescrypt specification](https://password-hashing.net/submissions/specs/yescrypt-v1.pdf)
- [The yescrypt C implementations](https://password-hashing.net/submissions/yescrypt-v1.tar.gz)
- [Colin Percival's scrypt paper](https://www.tarsnap.com/scrypt/scrypt.pdf)
- [The scrypt Internet-Draft](https://tools.ietf.org/html/draft-josefsson-scrypt-kdf-02)
Optimization
---------------
Currently, none of the implementations are optimized.
Using a non-optimized implementation in production is a security weakness. This
is because you are forced to use weaker parameters than you could have with an
optimized implementation, and therefore the attacker has more of an advantage.
Use an optimized native implementation if possible.
Audit Status
---------------
None of the code in this repository has been professionally reviewed. The code
here should be considered experimental and not used in production until this
notice is removed.
Reporting Security Bugs
-------------------------
Please disclose bugs publicly by opening an issue on GitHub. If you need to
disclose privately for some reason, or don't have a GitHub account, you can find
my contact information [here](https://defuse.ca/contact.htm).
The `ecmascript_simd` polyfill
--------------------------------
The polyfill for SIMD operations, in `javascript/ecmascript_simd.js`, was taken
from [tc38/ecmascript_simd](https://github.com/tc39/ecmascript_simd/) and
modified to support `shiftRightLogicalByScalar` on `Int32x4`.
Common API
----------
Each of the yescrypt implementations provides the following command-line API:
```
yescrypt-cli
```
Here, `` can be one of the following:
- `yescrypt`: Compute the `yescrypt` function using arguments `password` (hex
encoded), `salt` (hex encoded), `N`, `r`, `p`, `t`, `g`, `flags`, and `dkLen`
in that order.
- `pwxform`: Compute the `pwxform` function on the arguments `pwxblock` (hex
encoded) and `sbox` (hex encoded) in that order.
- `salsa20_8`: Compute the salsa20 function reduced to 8 rounds on the
hex-encoded cell provided as the next argument.
- `benchmark`: Run a performance benchmark (see below for arguments.).
When `` is `benchmark`, the next argument is the iteration count, and
then further arguments can be:
- `yescrypt`: Benchmark the yescrypt function, with the following arguments
being `N`, `r`, `p`, `t`, `g`, `flags`, and `dkLen` in that order, printing
the performance of computing yescypt with those parameters on random
passphrases and salts in c/s.
- `pwxform`: Benchmark the `pwxform` function on a random block and sbox,
printing the result in c/s.
- `salsa20_8`: Benchmark the `salsa20_8` function on a random cell, printing the
result in c/s.
Each implementation is expected to report its average performance for that many
iterations of the requested function. Implementations should strive to return as
accurate results as possible. If no meaningful accuracy is possible given the
provided iteration count, the benchmark command may fail with an error message.
The rationale for making each implementation have their own timing code is that
firstly, the overhead of process creation, etc. is not included in the running
time, and secondly, that each language "knows best" how to benchmark itself.
The rationale for not letting implementations decide the iteration count for
themselves is that the benchmark user is the one who decides how long they want
to run the benchmarks for and what kind of accuracy they expect.
Funding
=======
Taylor's work on this project was funded by [Google Summer of
Code](https://developers.google.com/open-source/gsoc/) and by 20% "fun friday"
time at [Zcash](https://z.cash).