BLAKE3-team

The BLAKE3 cryptographic hash function

By @oconnor663 @sevenps @veorq @zooko

[Rüdiger Klaehn @klaehnr]

To support content-addressed data transfer in @iroh_n0, we have been relying on a @Blake3Team fork for quite some time.

Not anymore. Thanks to @oconnor663, there is now a nice new hazmat API that has exactly what we need, and more.

For details: https://t.co/pKtR7ZK76a

[BLAKE3-team @Blake3Team]

The `blake3` Rust crate just added a `hazmat` module: https://t.co/lFxgbF2qPx. The goal is to support advanced use cases like Iroh and Bao without requiring undocumented APIs or forking the crate. If you like library docs with scary warnings at the top, take a look.

[Saito Network 🟥 @SaitoOfficial]

P2P Chat with Blake3 Hash Author @oconnor663

Wonderful guest and fascinating conversation behind the tech that links blocks in Saito together, and more...

Learn about the tech that makes Saito tick from an industry expert and a gracious teacher - Thanks Jack!

[Jack O'Connor @oconnor663]

I did an interview about BLAKE3 with the @SaitoOfficial folks: https://t.co/PER2nIKA0e

[BLAKE3-team @Blake3Team]

Version 1.5.4 includes new assembly optimizations from @sevenps for long outputs, bringing them into line with existing performance for long inputs. https://t.co/ftjzQSIomU. If you have an AVX-512-supporting Linux machine, give these a try: cargo +nightly bench xof

[BLAKE3-team @Blake3Team]

Use Fast Data Algorithms: https://t.co/2dqXNUJSmd

[BLAKE3-team @Blake3Team]

BLAKE3 in Lua: https://t.co/72VYR18kYu

[Anjan Roy @meanjanroy]

My latest project implements BLAKE3 cryptographic hash function using SYCL

1GB input hashed on

Nvidia Tesla V100: ~12ms
Intel Iris Xe Max GPU: ~38ms
Intel Xeon Platinum 2.6Ghz 128 CPUs: ~24ms

Single source targeting CPU, GPU 😉

See https://t.co/5zC5XXJsz6

#sycl @Blake3Team

[BLAKE3-team @Blake3Team]

BLAKE3 version 1.0 was just released on GitHub and https://t.co/hnq55MJLvB. https://t.co/u5J99fs1Ok

[BLAKE3-team @Blake3Team]

@awakecoding That makes sense. HKDF-SHA256 is a perfectly reasonable choice for most applications.

[BLAKE3-team @Blake3Team]

@awakecoding The goal of the derive_key() approach is to make domain separation as reliable as possible between uncoordinated callers who are sharing key material. Obviously "not sharing key material" is the safest option when you have a choice, but we live in a messy world.

[BLAKE3-team @Blake3Team]

@awakecoding Another difference between derive_key() and HKDF is that derive_key() is stricter about how its inputs should be used. The first argument must always be a hardcoded context/purpose string, and the second input is everything else. HKDF has three arguments, all somewhat freeform.

[BLAKE3-team @Blake3Team]

BLAKE3 implemented in Scala: https://t.co/VTrKaXqauM

[Dan Guido @dguido]

Reverie uses bitslicing, parallelism, fast crypto primitives (blake3, chacha12), and a streaming verifier and prover to offer high-performance ZK proofs over a network. And it's written in Rust. https://t.co/anKFeijV47

[BLAKE3-team @Blake3Team]

BLAKE3 bindings for .NET: https://t.co/iUmFM955nZ

[BLAKE3-team @Blake3Team]

Ice Lake benchmarks: https://t.co/ekDCbV8bNJ

[BLAKE3-team @Blake3Team]

The first SUPERCOP benchmark for BLAKE3 on AVX-512 is in: https://t.co/RGFKloGoRX

[BLAKE3-team @Blake3Team]

BLAKE3 bindings for Haskell: https://t.co/2RDPEDpLxa