BLAKE3-specs
multihash
BLAKE3-specs | multihash | |
---|---|---|
8 | 9 | |
158 | 876 | |
0.0% | 0.0% | |
0.0 | 3.3 | |
almost 2 years ago | 9 months ago | |
HTML | Shell | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
BLAKE3-specs
-
Reasons to Prefer Blake3 over Sha256
We put a lot of effort into section 5.1.2 of https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak..., and the relatively more complicated part of BLAKE3 (incrementally building the Merkle tree) ends up being ~4 lines of code. Let me know what you think.
-
Why do we even need HKDF's?
BLAKE3 is a new function which includes a KDF mode, and is significantly faster than HKDF-SHA256. However, it hasn't seen as much cryptanalysis as more established functions, so I'm still somewhat wary of it (admittedly it's a reduced-round variant of BLAKE2s, with extra modes, so I'm not that wary, but it's still worth a warning).
-
A few questions...
The BLAKE3 spec is also pretty readable (though I think the graphics in the BLAKE2b paper make it a bit easier to understand).
-
Linux Kernel RNG is now Blake2 instead of SHA1 and 3x faster
> That's for 16KiB inputs.
BLAKE3 needs 16 KiB of input to hit the numbers in that bar chart, but BLAKE2s doesn't. It'll maintain its advantage over SHA-256 all the way down to the empty string. You can see this in Figure 3 of https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak.... (BLAKE3 is also faster than SHA-256 all the way down to the empty string, but not by as large a margin as the 16 KiB figures suggest.)
On the other hand, these measurements were done on machines without SHA-256 hardware acceleration. If you have that (and Intel chips from the past year do), then SHA-256 does a lot better of course.
-
I Have Settled on XChaCha20+Blake3 for AEAD
Its section 2.1 of the paper: https://github.com/BLAKE3-team/BLAKE3-specs/blob/master/blak...
Though, note, blake3 still provides enhanced resistance against the attacks against blake2 even in the case where you only have one block, due to the change in how the fundamental hashing primitive is used.
-
Consensus mechanism
Consensus is done with Blockmania, a PBFT consensus protocol. Link P2P networking stack (in progress) = libp2p. Link (currently we're using Serf for cluster membership, but this will be replaced by libp2p) We use Blake 3 for merkle tree and hashing algorithm. Link (amongst others that are standard, e.g. multisig) Lthash is used for block propagation and homomorphic hashing, and to extend for bootstrapping. Link For transaction and balance privacy we use:
multihash
-
Reasons to Prefer Blake3 over Sha256
Since you seem to have done a fair bit of research in this area, do you have any opinions or thoughts about the Multihash format?
https://multiformats.io/multihash/
It fills in some of the blanks in your "prefixing the hash with the value of the enum for the hash" step.
-
🎉 accumulate_api v0.3.0 released
This library supports latest Accumulate API v3 features with multibase and multihash addresses, and adds many corrections to the usability and structure of the library. Overall it's different from other clients that are generated from the Go codebase, and developed for developers with canonical Dart approaches.
-
Using Zlib-Searcher to Search the Z-Library Index for Books on the IPFS Network
> IPFS now uses base58btc exclusively
That's blatantly wrong. IPFS supports 25 different base representations (https://github.com/multiformats/multibase/blob/master/multib...).
In fact, recently, two community members decided to implement a new base encoding with emojis for fun:
https://cid.ipfs.tech/#%F0%9F%9A%80%F0%9F%AA%90%E2%AD%90%F0%...
https://github.com/multiformats/multihash supports at the very least SHA1 SHA2-256 SHA2-512 SHA3/Keccak Blake2b-256/Blake2b-512/Blake2s-128/Blake2s-256 Blake3 and Strobe. Hashes in IPFS are being standardised through the IETF and W3C https://www.ietf.org/id/draft-multiformats-multihash-05.html.
If you need rhash, you are welcome to submit a PR! We also have a grants program you can use to be rewarded for this.
- multihash - self describing hashes for future proofing
- Self describing hashes – for future proofing
- Mutlihash: Self-Describing Hashes
-
Whatever happened to SHA-256 support in Git?
Also check out multihash from the IPFS folks: https://github.com/multiformats/multihash
It's a more robust, well-specified, interoperable version of this concept.
Though it's probably overkill if you control both the consumer and producer side (i.e. don't need the interoperability) and are just looking to make hash upgrades smoother, in that case a simple version prefix like Go's approach described above has lower overhead.
- Calculate QmHash of any file
-
Contributing to rust-libp2p
Previously, a PeerId was internally represented as a multihash, a scheme to specify different hashes with their respective hashing methods. These hashes were then encoded in base58btc.
What are some alternatives?
BLAKE3 - the official Rust and C implementations of the BLAKE3 cryptographic hash function
rust-cid - CID in rust
XKCP - eXtended Keccak Code Package
Gitolite - Hosting git repositories -- Gitolite allows you to setup git hosting on a central server, with very fine-grained access control and many (many!) more powerful features.
experimental-caead - Experimental committing AEAD designed by Soatok.
rust-libp2p - The Rust Implementation of the libp2p networking stack.
Hakobu
accumulate - MIRROR ONLY ✻ Accumulate shifts the paradigm for how blockchains manage data, tokens, and users
bao - an implementation of BLAKE3 verified streaming
go-benchmarks - Comprehensive and reproducible benchmarks for Go developers and architects.