9e0830065e | ||
---|---|---|
.gitignore | ||
README.md | ||
a.out.js | ||
a.out.o1.js | ||
a.out.o2.js | ||
a.out.o2.js.mem | ||
a.out.o3.js | ||
a.out.o3.js.mem | ||
a.out.o3opt.js | ||
a.out.o3opt.js.mem | ||
blake2b.c | ||
blake2b.js | ||
blake2s.js | ||
generated_test_vectors.txt | ||
index.js | ||
package.json | ||
test_blake2b.js | ||
test_blake2s.js | ||
util.js |
README.md
BLAKE.js
Pure Javascript implementation of the BLAKE2b and BLAKE2s hash functions.
BLAKE is the default family of hash functions in the venerable NaCl crypto library. Like SHA2 and SHA3 but unlike MD5 and SHA1, BLAKE offers solid security. With an optimized assembly implementation, BLAKE can be faster than all of those other hash functions.
Of course, this implementation is in Javascript, so it won't be winning any speed records. More under Performance below. It's short and sweet, less than 500 LOC. As far as I know, it's the only package available today to compute BLAKE2s and BLAKE2b in a browser.
Example
var blake = require('blakejs')
console.log(blake.blake2bHex('abc'))
// prints ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d17d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923
console.log(blake.blake2sHex('abc'))
// prints 508c5e8c327c14e2e1a72ba34eeb452f37458b209ed63a294d999b4c86675982
Emscripten
This branch tests out an alternative asm.js implementation, using Emscripten on the reference C implementation from the BLAKE RFC.
Results so far are surprisingly bad!
Best result so far obtained with:
./emcc ~/blakejs/blake2b.c -O3 -Oz --closure 1 -s NO_BROWSER=1 -s NO_FILESYSTEM=1 -s NO_EXIT_RUNTIME=1 -s EXPORTED_RUNTIME_METHODS="['_malloc','_free','writeArrayToMemory','HEAPU8']" -s EXPORTED_FUNCTIONS="['_blake2b']" -o ~/blakejs/a.out.o3opt.js
- Code size is 43KB minified / 18KB gzipped even with
-Oz
and the Closure compiler - Compare that to 4KB minified / 1.8KB gzipped using the Closure compiler on the original handwritten code. See the
closure-compiler
branch. - Speed is 3x worse than the handwritten port, 6.4 MB/sec vs 15.2 MB/sec on a 2.2GHz i7-4770HQ
- The original is pretty clean, and of course the Emscripten output is ugly and unreadable
API
First, blake2b
computes a BLAKE2b hash.
Pass it a string, Buffer
, or Uint8Array
containing bytes to hash, and it will return a Uint8Array
containing the hash.
// Computes the BLAKE2B hash of a string or byte array, and returns a Uint8Array
//
// Returns a n-byte Uint8Array
//
// Parameters:
// - input - the input bytes, as a string, Buffer, or Uint8Array
// Strings are converted to UTF8 bytes
// - key - optional key Uint8Array, up to 64 bytes
// - outlen - optional output length in bytes, default 64
function blake2b(input, key, outlen) {
[...]
}
For convenience, blake2bHex
takes the same arguments and works the same way, but returns a hex string.
Second, you can use blake2b_init
, blake2b_update
, and blake2b_final
to compute the hash of a stream of bytes.
var KEY = null // optional key
var OUTPUT_LENGTH = 64 // bytes
var context = blake2b_init(OUTPUT_LENGTH, KEY)
...
// each time you get a byte array from the stream:
blake2b_update(context, bytes)
...
// finally, once the stream has been exhausted
var hash = blake2b_final(context)
// returns a 64-byte hash, as a Uint8Array
Finally, all five of these functions (blake2b
, blake2bHex
, blake2b_init
, blake2b_update
, and blake2b_final
) have blake2s
equivalents.
The inputs are identical except that maximum key size and maximum output size are 32 bytes instead of 64.
Limitations
-
Can only handle up to 2**53 bytes of input
If your webapp is hashing more than 8 petabytes, you may have other problems :)
Testing
- Examples from the RFC
- BLAKE2s self-test from the RFC
- Examples from http://pythonhosted.org/pyblake2/examples.html
- A longer set of test vectors generated by https://github.com/jedisct1/crypto-test-vectors/tree/master/crypto/hash/blake2/blake2b/nosalt-nopersonalization/generators/libsodium
Performance
BLAKE2b: 15.2 MB / second on a 2.2GHz i7-4770HQ
BLAKE2s: 20.4 MB / second
¯\_(ツ)_/¯
If you're using BLAKE2b in server side node.js code, you probably want the native wrapper which should be able to do several hundred MB / second on the same processor.
If you're using BLAKE2b in a web app, 15 MB/sec might be fine.
Javascript doesn't have 64-bit integers, and BLAKE2b is a 64-bit integer algorithm. Writing it withUint32Array
is not that fast. BLAKE2s is a 32-bit algorithm, so it's a bit faster.
If we want better machine code at the expense of gross-looking Javascript, we could use asm.js
License
Creative Commons CC0. Ported from the reference C implementation in RFC 7693.