3 ms·

Agreed. Blake3 is super promising as cryptographic hash function family due to its software performance (not sure if anyone has tried making hardware designs fo

Agreed. Blake3 is super promising as cryptographic hash function family due to its software performance (not sure if anyone has tried making hardware designs for it), but SHA2 hardware acceleration is extremely common and makes it good enough. And while SHA3 software performance is poor it's quite good in hardware, so as more chips accelerate it it'll become generally viable. So while Blake3 looks nice, there's not a whole ton of need for it right now, and I doubt it'll become SHA4 ever.

aliqot 4y ago
Sha3 is performant, but I'll always give it the stink eye because of NIST selecting the winner, then modifying their solution before standardization without sufficient explanation. Read the room, this is cryptography; one does not simply add mystery padding and rush off to the printing press. https://www.schneier.com/blog/archives/2013/10/will_keccak_sha-3.html https://www.schneier.com/blog/archives/2013/10/will_keccak_s... https://en.wikipedia.org/wiki/SHA-3#Padding https://en.wikipedia.org/wiki/SHA-3#Padding
- dchest 4y ago
  All good changes, giving us SHAKE functions and the rest of useful variants based on domain separation in padding.
- WhitneyLand 4y ago
  How much did your opinion change after reading the 10/5 update to Schneier’s post? From your first link: I misspoke when I wrote that NIST made “internal changes” to the algorithm. That was sloppy of me. The Keccak permutation remains unchanged. What NIST proposed was reducing the hash function’s capacity in the name of performance. One of Keccak’s nice features is that it’s highly tunable. I do not believe that the NIST changes were suggested by the NSA. Nor do I believe that the changes make the algorithm easier to break by the NSA. I believe NIST made the changes in good faith, and the result is a better security/performance trade-off.
  - booi 4y ago
    Nice try NSA, that’s exactly what you want us to believe! jk I’m sure it’s fine… probably
    - macksd 4y ago
      I'm sure it's fine if you use James Mickens' Mossad / Not-Mossad threat model.
  - a1369209993 4y ago
    Can't speak for aliqot, but I am now somewhat more confident that the NIST changes were suggested by the NSA, and slightly more confident (or at least less unconfident) that SHA-3 is insecure. I still think it's probably fine, but I feel better about insisting on SHA-2+mitigations or blake3 instead now, even if the main problem with SHA-3 is its being deliberately designed to encourage specialized hardware accelleration (cf AES and things like Intel's aes-ni). (To be clear, the fact that Schneier claims to "believe NIST made the changes in good faith" is weak but nonzero evidence that they did not. I don't see any concrete evidence for a backdoor, although you obviously shouldn't trust me either.)
    - andreareina 4y ago
      Does Schneier have some association to the NSA I don't know about? I'd normally consider that statement as weak evidence they did make the changes in good faith.
      - TedDoesntTalk 4y ago
        > Does Schneier have some association to the NSA I don't know about? Do you think he’d disclose it if he did?
        andreareina 4y ago
        What does that have to do with anything? AFAIK Schneier's public actions are consistently pro-privacy, pro-encryption. Implying otherwise should be accompanied by evidence don't you think?
- nicolashahn 4y ago
  how else do you add a backdoor?
  - Dylan16807 4y ago
    The original padding, as bits, was 100000...0001 The new padding prepends either 01, 11, or 1111 depending on the variant of SHA-3. That way the different variants don't sometimes give the same [partial] hash. It was weird to toss that in at the last second but there's no room for a backdoor there.
- yarg 4y ago
  Skein always seemed interesting to me: https://en.wikipedia.org/wiki/Skein_(hash_function) https://en.wikipedia.org/wiki/Skein_(hash_function) But I've had a soft spot for Schneier since this (pre-Snowden) blog post on Dual_EC_DRBG: https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html https://www.schneier.com/blog/archives/2007/11/the_strange_s....
- Perseids 4y ago
  It is fair to criticize NIST for enabling rumors about them weakening SHA3, but these are rumors only, nothing more. Please, everyone, stop spreading them. SHA3 is the same Keccak that has gone through extensive scrutiny during the SHA3 competition, and, as far as anyone can tell, it is rock solid. Don't trust NIST, don't trust me, trust the designers of Keccak, who tell you that NIST did not break it: > NIST's current proposal for SHA-3, namely the one presented by John Kelsey at CHES 2013 in August, is a subset of the Keccak family. More concretely, one can generate the test vectors for that proposal using the Keccak reference code (version 3.0 and later, January 2011). This alone shows that the proposal cannot contain internal changes to the algorithm. https://keccak.team/2013/yes_this_is_keccak.html https://keccak.team/2013/yes_this_is_keccak.html
- pilsetnieks 4y ago
  > Read the room, this is cryptography; one does not simply add mystery padding and rush off to the printing press. In fact, one actually has done almost exactly that: https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA's_involvement_in_the_design https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA's...
- 15155 4y ago
  I've implemented SHA-3 and Keccak in hardware (FPGA) and software (CPU, GPU) countless times: there's zero scenario where this single byte change occurring before 24 rounds of massive permutation has any measurable effect on the security of this hash function.
KMag 4y ago
As far as Blake3 in hardware for anything other than very low-power smart cards or similar: Blake3 was designed from the ground up to be highly optimized for vector instructions operating on four vectors, each of 4 32-bit words. If you already have the usual 4x32 vector operations, plus a vector permute (to transform the operations across the diagonal of your 4x4 matrix into operations down columns) and the usual bypass network to reduce latency, I think it would rarely be worth the transistor budget to create dedicated Blake3 (or Blake2s/b) instructions. In contrast, SHA-3's state is conceptually five vectors each of five 32-bit words, which doesn't map as neatly onto most vector ISAs. As I remember, it has column and row operations rather than column and diagonal operations that parallelize better on vector hardware. SHA-2 is a Merkle-Damgard construction where the round function is a Davies-Meyer construction where the internal block cipher is a highly unbalanced Feistel cipher. Conceptually, you have a queue of 8 words (32-bit or 64-bit, depending on which variant). Each operation pops the first word from the queue, combines it in a nonlinear way with 6 of the other words, adds one word from the "key schedule" derived from the message, and pushes the result on the back of the queue. The one word that wasn't otherwise used is increased by the sum of the round key and a non-linear function of 3 of the other words. As you might imagine, this doesn't map very well onto general-purpose vector instructions. This cipher is wrapped in a step (Davies-Meyer construction) where you save a copy of the state, encrypt the state using the next block of the message, and then add the saved copy to the encrypted result (making it non-invertible, making meet-in-the middle attacks much more difficult). The key schedule uses a variation on a lagged Fibonacci generator to expand each message block into a larger number of round keys.
- oconnor663 4y ago
  > Blake3 was designed from the ground up to be highly optimized for vector instructions operating on four vectors, each of 4 32-bit words. This is true, and the BLAKE family inherits this structure from ChaCha, but there's also more to it than that. If you have enough input to fill many blocks, you can run multiple blocks in parallel. In this situation, rather than dividing up the 16 words of a block into four vectors, you put each word in a different vector, and the words of each vector represent the same position in different blocks. (I.e rather than representing columns or rows, the vectors point "out of the page.) There are several benefits to this arrangement: 1. You don't need to do that diagonalization operation anymore. 2. If your CPU supports "instruction-level parallelism" for vector operation, working across the four words/vectors in a row gets to take advantage of that. 3. Best of all, you're no longer limited to 4-word vectors. If you have enough input to fill 8 blocks (AVX2) or 16 blocks (AVX-512), you can use those much larger instruction sets. This is all easy to take advantage of in a stream cipher like ChaCha, because each block is independent. With a hash function, things are more complicated, because you usually have data dependencies between different blocks. That's why the tree structure of BLAKE3 (or somewhat similarly, KangarooTwelve) is so important for performance. It's not just about multithreading; it also about SIMD. See section 5.3 of the BLAKE3 paper for more on this.
StreamBright 4y ago
> Blake3 is super promising as cryptographic hash function family due to its software performance I am shocked how fast it is. Just tried it on several files. It is blazing fast. brew install b3sum on mac.
- whateveracct 4y ago
  Oh yeah Blake3 is just the best if it's accessible to you. I get that other algorithms are more ubiquitous. But if I need a crypto hash, I consider Blake first.
  - 15155 4y ago
    As a hardware developer: Blake3 is better than SHA1/2, but still far inferior to SHA-3 with regards to implementation area or ease.
silisili 4y ago
Random question - I see BLAKE written in caps. Is it an acronym of something?
- detaro 4y ago
  I don't think so? BLAKE is an evolution of an earlier proposal for a family of hash functions called LAKE, but the paper for that does not explain the name at least.

aliqot 4y ago

Sha3 is performant, but I'll always give it the stink eye because of NIST selecting the winner, then modifying their solution before standardization without sufficient explanation. Read the room, this is cryptography; one does not simply add mystery padding and rush off to the printing press. https://www.schneier.com/blog/archives/2013/10/will_keccak_sha-3.html https://www.schneier.com/blog/archives/2013/10/will_keccak_s... https://en.wikipedia.org/wiki/SHA-3#Padding https://en.wikipedia.org/wiki/SHA-3#Padding

dchest 4y ago
All good changes, giving us SHAKE functions and the rest of useful variants based on domain separation in padding.
WhitneyLand 4y ago
How much did your opinion change after reading the 10/5 update to Schneier’s post? From your first link: I misspoke when I wrote that NIST made “internal changes” to the algorithm. That was sloppy of me. The Keccak permutation remains unchanged. What NIST proposed was reducing the hash function’s capacity in the name of performance. One of Keccak’s nice features is that it’s highly tunable. I do not believe that the NIST changes were suggested by the NSA. Nor do I believe that the changes make the algorithm easier to break by the NSA. I believe NIST made the changes in good faith, and the result is a better security/performance trade-off.
- booi 4y ago
  Nice try NSA, that’s exactly what you want us to believe! jk I’m sure it’s fine… probably
  - macksd 4y ago
    I'm sure it's fine if you use James Mickens' Mossad / Not-Mossad threat model.
- a1369209993 4y ago
  Can't speak for aliqot, but I am now somewhat more confident that the NIST changes were suggested by the NSA, and slightly more confident (or at least less unconfident) that SHA-3 is insecure. I still think it's probably fine, but I feel better about insisting on SHA-2+mitigations or blake3 instead now, even if the main problem with SHA-3 is its being deliberately designed to encourage specialized hardware accelleration (cf AES and things like Intel's aes-ni). (To be clear, the fact that Schneier claims to "believe NIST made the changes in good faith" is weak but nonzero evidence that they did not. I don't see any concrete evidence for a backdoor, although you obviously shouldn't trust me either.)
  - andreareina 4y ago
    Does Schneier have some association to the NSA I don't know about? I'd normally consider that statement as weak evidence they did make the changes in good faith.
    - TedDoesntTalk 4y ago
      > Does Schneier have some association to the NSA I don't know about? Do you think he’d disclose it if he did?
      - andreareina 4y ago
        What does that have to do with anything? AFAIK Schneier's public actions are consistently pro-privacy, pro-encryption. Implying otherwise should be accompanied by evidence don't you think?
nicolashahn 4y ago
how else do you add a backdoor?
- Dylan16807 4y ago
  The original padding, as bits, was 100000...0001 The new padding prepends either 01, 11, or 1111 depending on the variant of SHA-3. That way the different variants don't sometimes give the same [partial] hash. It was weird to toss that in at the last second but there's no room for a backdoor there.
yarg 4y ago
Skein always seemed interesting to me: https://en.wikipedia.org/wiki/Skein_(hash_function) https://en.wikipedia.org/wiki/Skein_(hash_function) But I've had a soft spot for Schneier since this (pre-Snowden) blog post on Dual_EC_DRBG: https://www.schneier.com/blog/archives/2007/11/the_strange_sto.html https://www.schneier.com/blog/archives/2007/11/the_strange_s....
Perseids 4y ago
It is fair to criticize NIST for enabling rumors about them weakening SHA3, but these are rumors only, nothing more. Please, everyone, stop spreading them. SHA3 is the same Keccak that has gone through extensive scrutiny during the SHA3 competition, and, as far as anyone can tell, it is rock solid. Don't trust NIST, don't trust me, trust the designers of Keccak, who tell you that NIST did not break it: > NIST's current proposal for SHA-3, namely the one presented by John Kelsey at CHES 2013 in August, is a subset of the Keccak family. More concretely, one can generate the test vectors for that proposal using the Keccak reference code (version 3.0 and later, January 2011). This alone shows that the proposal cannot contain internal changes to the algorithm. https://keccak.team/2013/yes_this_is_keccak.html https://keccak.team/2013/yes_this_is_keccak.html
pilsetnieks 4y ago
> Read the room, this is cryptography; one does not simply add mystery padding and rush off to the printing press. In fact, one actually has done almost exactly that: https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA's_involvement_in_the_design https://en.wikipedia.org/wiki/Data_Encryption_Standard#NSA's...
15155 4y ago
I've implemented SHA-3 and Keccak in hardware (FPGA) and software (CPU, GPU) countless times: there's zero scenario where this single byte change occurring before 24 rounds of massive permutation has any measurable effect on the security of this hash function.

KMag 4y ago

As far as Blake3 in hardware for anything other than very low-power smart cards or similar: Blake3 was designed from the ground up to be highly optimized for vector instructions operating on four vectors, each of 4 32-bit words. If you already have the usual 4x32 vector operations, plus a vector permute (to transform the operations across the diagonal of your 4x4 matrix into operations down columns) and the usual bypass network to reduce latency, I think it would rarely be worth the transistor budget to create dedicated Blake3 (or Blake2s/b) instructions. In contrast, SHA-3's state is conceptually five vectors each of five 32-bit words, which doesn't map as neatly onto most vector ISAs. As I remember, it has column and row operations rather than column and diagonal operations that parallelize better on vector hardware. SHA-2 is a Merkle-Damgard construction where the round function is a Davies-Meyer construction where the internal block cipher is a highly unbalanced Feistel cipher. Conceptually, you have a queue of 8 words (32-bit or 64-bit, depending on which variant). Each operation pops the first word from the queue, combines it in a nonlinear way with 6 of the other words, adds one word from the "key schedule" derived from the message, and pushes the result on the back of the queue. The one word that wasn't otherwise used is increased by the sum of the round key and a non-linear function of 3 of the other words. As you might imagine, this doesn't map very well onto general-purpose vector instructions. This cipher is wrapped in a step (Davies-Meyer construction) where you save a copy of the state, encrypt the state using the next block of the message, and then add the saved copy to the encrypted result (making it non-invertible, making meet-in-the middle attacks much more difficult). The key schedule uses a variation on a lagged Fibonacci generator to expand each message block into a larger number of round keys.

oconnor663 4y ago
> Blake3 was designed from the ground up to be highly optimized for vector instructions operating on four vectors, each of 4 32-bit words. This is true, and the BLAKE family inherits this structure from ChaCha, but there's also more to it than that. If you have enough input to fill many blocks, you can run multiple blocks in parallel. In this situation, rather than dividing up the 16 words of a block into four vectors, you put each word in a different vector, and the words of each vector represent the same position in different blocks. (I.e rather than representing columns or rows, the vectors point "out of the page.) There are several benefits to this arrangement: 1. You don't need to do that diagonalization operation anymore. 2. If your CPU supports "instruction-level parallelism" for vector operation, working across the four words/vectors in a row gets to take advantage of that. 3. Best of all, you're no longer limited to 4-word vectors. If you have enough input to fill 8 blocks (AVX2) or 16 blocks (AVX-512), you can use those much larger instruction sets. This is all easy to take advantage of in a stream cipher like ChaCha, because each block is independent. With a hash function, things are more complicated, because you usually have data dependencies between different blocks. That's why the tree structure of BLAKE3 (or somewhat similarly, KangarooTwelve) is so important for performance. It's not just about multithreading; it also about SIMD. See section 5.3 of the BLAKE3 paper for more on this.

StreamBright 4y ago

> Blake3 is super promising as cryptographic hash function family due to its software performance I am shocked how fast it is. Just tried it on several files. It is blazing fast. brew install b3sum on mac.

whateveracct 4y ago
Oh yeah Blake3 is just the best if it's accessible to you. I get that other algorithms are more ubiquitous. But if I need a crypto hash, I consider Blake first.
- 15155 4y ago
  As a hardware developer: Blake3 is better than SHA1/2, but still far inferior to SHA-3 with regards to implementation area or ease.

silisili 4y ago

Random question - I see BLAKE written in caps. Is it an acronym of something?

detaro 4y ago
I don't think so? BLAKE is an evolution of an earlier proposal for a family of hash functions called LAKE, but the paper for that does not explain the name at least.