Comments (3)
Thank you very much for the clarification, explanation, and recommendation. Makes sense.
Outcome: CycloneDX v1.2 will simply support BLAKE3 without regard to length as it doesn't make sense to include it.
from blake3-specs.
All very good questions! I'm actually surprised this hasn't come up before. To the extent possible, I'd recommend just calling it BLAKE3
and having the output be 32 bytes. There are some key differences between BLAKE2 and BLAKE3 that motivate that recommendation:
-
In BLAKE2 (setting aside BLAKE2X) the maximum output length of each function was also the length necessary to achieve maximum security. So for example, it could be reasonable to say that BLAKE2b-512 is more secure than BLAKE2b-256. (Whether anyone actually needs that level of security is a different question.) In contrast, BLAKE3 (like BLAKE2X) can have any output length. But above 32 bytes, adding additional bytes of output does not increase security, because security is ultimately capped by the internal state size. There is no security benefit to using 64-byte BLAKE3 over 32-byte BLAKE3.
-
In BLAKE2 (setting aside one of the modes of BLAKE2X) outputs of length X and outputs of length X+1 are independent of each other. For example, if you know the BLAKE2b-256 hash of my input, that doesn't tell you anything about the BLAKE2b-512 hash of the same input. This is not the case with BLAKE3. A BLAKE3 output of length X and an output of length X+1 differ only in that very last byte; the first is a prefix of the second. The main reason this is done is that extendable output functions (XOFs) need a mode where you don't know how many bytes you're going to need in advance, and it's simpler to have this be the only mode than to have multiple different XOF modes.
For those reasons, I think labeling functions like BLAKE3-64
/BLAKE3-512
could be more harmful than helpful. Users might reasonably expect them to be independent from each other, as most* of the BLAKE2 algorithms and all of the SHA-family algorithms are. Users might also expect that larger numbers mean more security, when in practice they just mean more space. I think it would be best if there was only BLAKE3
and it was almost always 32 bytes of output.
* Again this "most" situation is why having more than one XOF mode is a big downside. I think it can be better to never have a feature, than to sometimes have it.
Also, one additional question. What is the highest length you envision the 'real world' would use. My initial thought would be a length of 128 which would produce a 256 character hex string.
I think essentially everyone using BLAKE3 as a "regular" hash function -- where you work with its output as a single value -- is going to want 32 bytes. The XOF is for somewhat more exotic uses. For example, if you wanted to stretch one random 32-byte key into 100 different keys (probably using the BLAKE3 derive_key
function, but either way), you'd produce an output that's 3200 bytes long and then slice it up. The Ed25519 algorithm is kind of like this internally, in that it needs 64 bytes of hash output, which it splits into two different secrets. Or maybe you could use BLAKE3 as a sort of CSPRNG, with the input as a seed, and an arbitrary amount of output. But again, I don't think any of these use cases look much like "outputting a single value", and I think all the use cases that do look like that should use 32 bytes and just call it BLAKE3. Let me know if all that makes sense.
from blake3-specs.
from blake3-specs.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from blake3-specs.