blake3-team / blake3-specs Goto Github PK

Hello,

I'm working on a new release of the CycloneDX software bill of material specification and I'm including BLAKE2b and would like to include BLAKE3 as well.

This is a non-technical question about how the output length value affects the label in which end users apply to BLAKE3 when using it.

BLAKE2b-256:
b2sum -l 256 returns 64 hex characters.

by contrast:
b3sum -l 32 returns 64 hex characters.

Should this be referred to as BLAKE3-32? If not, what should it be labeled as?

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.

If this is the case, then would labeling these as:

• BLAKE3-32
• BLAKE3-64
• BLAKE3-128

make sense?

Sorry for the noob questions. Just now installed BLAKE3 so completely unaware of the specs or history and I'm nearing the release of CycloneDX v1.2 and I'd like to get the labeling correct.

Transferring this from BLAKE3-team/BLAKE3#347 created by @dralley

The OpenSSL project states that "a necessary condition to include a new algorithm into the main code base is that the algorithm should be part of a standard from a recognized standardization body", and also that "Informational RFCs are sufficient for adopting an algorithm by OpenSSL."

openssl/openssl#11613

It would be great to (eventually) see an implementation of Blake3 in OpenSSL, because that would open the door to it being included in places like the Python standard library. It seems like they might be open to it, but this would be a prerequisite.

As an example here is the informational RFC for Blake 2 https://www.rfc-editor.org/rfc/rfc7693.html

Hello.

Comparing to what I see at RFC for BLAKE2, where table with similar role called 'SIGMA', data for BLAKE3 not full at specification.

For another side, something might be missed by me, so addition description about this situation would be nice.
That why no accompanying pull request for this issue exists at this moment.

If it was created it will contain rest of table that can be founded at Rust and C reference implementations.

-    2 & 6 & 3 & 10 & 7 & 0 & 4 & 13 & 1 & 11 & 12 & 5 & 9 & 14 & 15 & 8 \\
+    2 & 6 & 3 & 10 & 7 & 0 & 4 & 13 & 1 & 11 & 12 & 5 & 9 & 14 & 15 & 8 \\ \midrule
+    3 & 4 & 10 & 12 & 13 & 2 & 7 & 14 & 6 & 5 & 9 & 0 & 11 & 15 & 8 & 1 \\ \midrule
+    10 & 7 & 12 & 9 & 14 & 3 & 13 & 15 & 4 & 0 & 11 & 2 & 5 & 8 & 1 & 6 \\ \midrule
+    12 & 13 & 9 & 11 & 15 & 10 & 14 & 8 & 7 & 2 & 5 & 3 & 0 & 1 & 6 & 4 \\ \midrule
+    9 & 14 & 11 & 5 & 8 & 12 & 15 & 1 & 13 & 3 & 0 & 10 & 2 & 6 & 4 & 7 \\ \midrule
+    11 & 15 & 5 & 0 & 1 & 9 & 8 & 6 & 14 & 10 & 2 & 12 & 3 & 4 & 7 & 13 \\

Thank you.

Dear team,
I'm working on a simple took to test the speed of Blake3 vs the SHA implementations. I have this code saved to GitHub. While the code is just as fast as b3sum, my HTOP is not showing that multiple threads are being engaged. Could it be that it is that fast? Could you spend a second looking at my Cargo.toml to make sure that I have the proper features for multi-threading? Thank you in advance.

https://github.com/SteveBattista/hash_test

This thread will be an ongoing collection of issues with the BLAKE3 design (not the implementation) that have been reported since release. The BLAKE3 paper itself isn't indended to be a living document, so folks working on future hash function designs might want to consider this thread an appendix to the paper. To be clear, we aren't aware of any major issues leading to practical attacks.

• Block-Cipher-Based Tree Hashing by Aldo Gunsing shows that an attacker who knows the input and the key (if any) can reverse the extended-output compression function to discover its other inputs. This includes the final block length (which this attacker already knows), the mode flags (which this attacker presumably knows), and the XOF output offset. The exposure of that offset isn't ideal, though for comparison, AES-CTR has a similar property when the attacker knows the AES key. We could've forced an attacker to brute force these parameters by feeding them forward into the final output, the same way the input state words are fed forward. This would be a very niche scenario to design for, and the brute force attack here would be practical in any case. But still it might've been nice to have, and the cost would've been low, just a handful of XORs at the end of the compression function. This issue was documented as a security note in BLAKE3-team/BLAKE3@ea3bc78.
• Antonio Marcedone and Balachandar Kesavan found a mistake in the Bao security argument related to seeking. In short, the chunk counter is important for secure seeks, but we weren't aware of that back when added it. The current design might still be the cleanest way to achieve what we need to achieve, but it's also possible that we'll spot some other issues as we try to formalize it. Here's the detailed writeup: oconnor663/bao#41

Cryptanalysis:

• Block-Cipher-Based Tree Hashing by Aldo Gunsing
• Approximate Modeling of Signed Difference and Digraph based Bit Condition Deduction: New Boomerang Attacks on BLAKE by Yonglin Hao et al

Hello,
in $2.6 of this spec, "BLAKE3 can produce outputs of any byte length 0 < 2^64."

I know the output length could be extended according the 64bit counter t, so the output could have 2^64's block for maximum.
But the output of one block is 512 bit (64 byte), why not the max output is 64 * 2^64 byte?

Thanks