HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
BLAKE3-team
BLAKE3
Assembly2020–2025
BLAKE3-team / BLAKE3

BLAKE3

the official Rust and C implementations of the BLAKE3 cryptographic hash function

24Distinct people
28Mentions
1Explicit recommenders
6.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

the official Rust and C implementations of the BLAKE3 cryptographic hash function

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

This is great! Many applications (like dedupe) don't need full crypto guarantees. If you need something fast, and crypto secure, I recommend checking out Blake3/b3sum. I'm just…

kortex used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year28 dated mentions

Observed mentions: 2020-01-09 17:29:19 UTC to 2025-11-07 09:03:49 UTC.

0510152020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 13 mentions; 1 submissions, 12 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 7 mentions; 1 submissions, 6 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC13112
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC716
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC404
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
BLAKE3 BLAKE3 is a cryptographic hash function that is: Much faster than MD5, SHA-1, SHA-2, SHA-3, and BLAKE2. Secure, unlike MD5 and SHA-1. And secure against length extension, unlike SHA-2. Highly parallelizable across any number of threads and SIMD lanes, because it's a Merkle tree on the inside. Capable of verified streaming and incremental updates, again because it's a Merkle tree. A PRF, MAC, KDF, and XOF, as well as a regular hash. One algorithm with no variants, which is fast on x86-64 and also on smaller architectures. The chart below is an example benchmark of 16 KiB inputs on a Cascade Lake-SP 8275CL server CPU from 2019. For more detailed benchmarks, see the BLAKE3 paper. BLAKE3 is based on an optimized instance of the established hash function BLAKE2 and on the original Bao tree mode. The specifications and design rationale are available in the BLAKE3 paper. The default output size is 256 bits. The current version of Bao implements verified streaming with BLAKE3. This repository is the official implementation of BLAKE3. It includes: The blake3 Rust crate, which includes optimized implementations for SSE2, SSE4.1, AVX2, AVX-512, NEON, and WASM, with automatic runtime CPU feature detection on x86. The rayon feature provides multithreading. The b3sum Rust crate, which provides a command line interface. It uses multithreading by default, making it an order of magnitude faster than e.g. sha256sum on typical desktop hardware. The C implementation, which like the Rust implementation includes SIMD optimizations (all except WASM), CPU feature detection on x86, and optional multithreading. See c/README.md. The Rust reference implementation, which is discussed in Section 5.1 of the BLAKE3 paper. This implementation is much smaller and simpler than the optimized ones above. If you want to see how BLAKE3 works, or you're writing a port that doesn't need multithreading or SIMD optimizations, start here. Ports of the reference implementation to other languages are hosted in separate repositories (C, Python). A set of test vectors that covers extended outputs, all three modes, and a variety of input lengths. BLAKE3 was designed by: @oconnor663 (Jack O'Connor) @sneves (Samuel Neves) @veorq (Jean-Philippe Aumasson) @zookozcash (Zooko) The development of BLAKE3 was sponsored by Electric Coin Company. BLAKE3 is also specified in the Community Cryptography Specification Project (C2SP). NOTE: BLAKE3 is not a password hashing algorithm, because it's designed to be fast, whereas password hashing should not be fast. If you hash passwords to store the hashes or if you derive keys from passwords, we recommend Argon2. Usage The b3sum utility The b3sum command line utility prints the BLAKE3 hashes of files or of standard input. Prebuilt binaries are available for Linux, Windows, and macOS (requiring the unidentified developer workaround) on the releases page. If you've installed Rust and Cargo, you can also build b3sum yourself with: cargo install b3sum If rustup didn't configure your PATH for you, you might need to go looking for the installed binary in e.g. ~/.cargo/bin. You can test out how fast BLAKE3 is on your machine by creating a big file and hashing it, for example: # Create a 1 GB file. head -c 1000000000 /dev/zero > /tmp/bigfile # Hash it with SHA-256. time openssl sha256 /tmp/bigfile # Hash it with BLAKE3. time b3sum /tmp/bigfile The blake3 crate To use BLAKE3 from Rust code, add a dependency on the blake3 crate to your Cargo.toml. Here's an example of hashing some input bytes: // Hash an input all at once. let hash1 = blake3::hash(b"foobarbaz"); // Hash an input incrementally. let mut hasher = blake3::Hasher::new(); hasher.update(b"foo"); hasher.update(b"bar"); hasher.update(b"baz"); let hash2 = hasher.finalize(); assert_eq!(hash1, hash2); // Extended output. OutputReader also implements Read and Seek. let mut output = [0; 1000]; let mut output_reader = hasher.finalize_xof(); output_reader.fill(&mut output); assert_eq!(hash1, output[..32]); // Print a hash as hex. println!("{}", hash1); Besides hash, BLAKE3 provides two other modes, keyed_hash and derive_key. The keyed_hash mode takes a 256-bit key: // MAC an input all at once. let example_key = [42u8; 32]; let mac1 = blake3::keyed_hash(&example_key, b"example input"); // MAC incrementally. let mut hasher = blake3::Hasher::new_keyed(&example_key); hasher.update(b"example input"); let mac2 = hasher.finalize(); assert_eq!(mac1, mac2); The derive_key mode takes a context string and some key material (not a password). The context string should be hardcoded, globally unique, and application-specific. A good default format for the context string is "[application] [commit timestamp] [purpose]": // Derive a couple of subkeys for different purposes. const EMAIL_CONTEXT: &str = "BLAKE3 example 2020-01-07 17:10:44 email key"; const API_CONTEXT: &str = "BLAKE3 example 2020-01-07 17:11:21 API key"; let input_key_material = b"usually at least 32 random bytes, not a password"; let email_key = blake3::derive_key(EMAIL_CONTEXT, input_key_material); let api_key = blake3::derive_key(API_CONTEXT, input_key_material); assert_ne!(email_key, api_key); The C implementation See c/README.md. Other implementations There are too many implementations out there for us to keep track of, but some highlights include an optimized Go implementation, Wasm bindings for Node.js and browsers, binary wheels for Python, .NET bindings, and a pure Java implementation. Contributing Please see CONTRIBUTING.md. Licenses This work is released into the public domain with CC0 1.0. Alternatively, it is licensed under any of the following: Apache 2.0 Apache 2.0 with LLVM exceptions Adoption & deployment Bazel Cargo Ccache Chia Clickhouse Farcaster IPFS Iroh LLVM Mold Nix Nym OpenZFS Redox Solana Tekken 8 Wasmer Miscellany @veorq and @oconnor663 did an interview with Cryptography FM. @oconnor663 did an interview with Saito.
Read the full README on GitHub

What Hacker News says

28 sources
> I don't think Blake3 has any hardware implementation at all yet. > https://github.com/BLAKE3-team/BLAKE3 > The blake3 Rust crate, which includes optimized implementations for SSE2, SSE4.1, AVX2, AVX-512, and NEON, with automatic runtime CPU feature detection on x86. The rayon feature provides multithreading. There aren't blake3 instructions, like some hardware has for SHA1, but it does use hardware acceleration. edit: Re-reading, I think you're saying "If we're going to talk about hardware acceleration, SHA1 still has the advantage because of specific instructions" - that is true.
In Reasons to Prefer Blake3 over Sha256
https://github.com/BLAKE3-team/BLAKE3/blob/master/media/spee... argues BLAKE2s is twice as fast compared to SHA256. One aspect switching from SHA1 to BLAKE2s does is it increases the total entropy a single compression operation adds to ChaCha20. This increases speed when folded BLAKE2s adds 128 bits per operation instead of folded SHA-1 that adds 80 bits. So that's two calls instead of four (I'm assuming they kept the folding). Another speedup comes from the fact the hash function constants aren't being filled with RDRAND inputs for every call. Finally, I'm not completely sure if increasing the hash size itself adds computational security against an attack where the internal state is compromised once, and the attacker tries to brute force the new state based on new output; My conjecture is the reseeding operation is atomic, i.e. that ChaC
Read the rest
ha20 won't yield anything until the reseed is complete. There shouldn't thus be any difference in this regard. I'd appreciate clarification wrt this.
In Linux Kernel RNG is now Blake2 instead of SHA1 and 3x faster

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.