6 ms·

The popularity of the Blake family annoys me, as I feel that it's overhyped. Sure, they're fast (on current hardware), but they're supposed to be cryptographic

by nsajko 5y ago

The popularity of the Blake family annoys me, as I feel that it's overhyped. Sure, they're fast (on current hardware), but they're supposed to be cryptographic hash functions. I know that BLAKE received some scrutiny in this regard, as part of the SHA3 competition. But then BLAKE was obsoleted by BLAKE2, which in turn was obsoleted by BLAKE3, making the claims to security less and less sensible. And all this is before the actual winner of SHA3 comes into the picture. With parameters as specified by SHA3 it's a lot slower than BLAKE3, but it is my understanding (IANAC) that (1) The SHA3 security margin can safely be decreased, as NIST set the security requirements too high. This is one of the reasons for the speed difference. (2) The sponge-based crypto popularized by Keccak (the SHA3 winner) is much more amenable to cryptanalysis than the more traditional crypto such as the functions in the Blake family. This means that Blake's security would be less sure even had it received the same level of scrutiny. But AFAIK Blake received much less scrutiny than Keccak, or even other sponge-based functions, such as the ones in the NIST Lightweight Crypto competition. https://csrc.nist.gov/Projects/lightweight-cryptography https://csrc.nist.gov/Projects/lightweight-cryptography https://keccak.team/2017/not_arx.html https://keccak.team/2017/not_arx.html

kortex 5y ago
A) I am not sure I'd say blake2 obsoletes blake, and certainly blake3 does not obsolete b2. They are a family, but still different algorithms. B) blake3, afaik, is not yet as thoroughly vetted as b2. C) I think some of the hype around b3 is deserved. It's crazy fast. If you don't care about crypto at all (e.g. file dedup), it's absolutely phenomenal. But the main downside of B3 right now is just novelty. Cryto algos are like fine wines. D) I don't know enough about Keccak vs Blake, but just because Blake2 has received less scrutiny, doesn't mean it's insufficient. I'm sure there are tradeoffs that the kernel editors have chosen. E: here's a link to some discussion: https://crypto.stackexchange.com/questions/31674/what-advantages-does-keccak-sha-3-have-over-blake2 https://crypto.stackexchange.com/questions/31674/what-advant...
- tptacek 5y ago
  Blake2 is already in lib/crypto in the kernel (it's needed for WireGuard, by the same author as this change); SHA3 and Blake3 are not. It's probably that simple.
- rincebrain 5y ago
  BLAKE3 is crazy fast...on x86, with extremely performant implementations using SIMD instructions present. On other platforms, where people haven't written such (or, IME, even on ARM when using their NEON version), it's nothing to write home about.
dlubarov 5y ago
As I understand it, the BLAKE family is built on a tweaked version of the ChaCha cipher, and security is proven under the assumption that this primitive behaves like a random function. Arguably we shouldn't be too concerned that blake3 is new, since ChaCha/Salsa are old primitives whose security has held up well. While the sponge framework is popular, it's rather inflexible, e.g. its sequential structure permits limited parallelism. There are more general sound hashing frameworks that still offer provable security, such as this one which blake3's analysis is based on: https://www.cs.ru.nl/~bmennink/pubs/18fsenew.pdf https://www.cs.ru.nl/~bmennink/pubs/18fsenew.pdf
oconnor663 5y ago
> Sure, they're fast (on current hardware), but they're supposed to be cryptographic hash functions. This is subjective, but in my mind the question of "how important is it for crypto to be fast?" is closely related to the question of "how many crypto options should we give people?" Like, should we design "slower, maximum-security, military-grade crypto for top secret material" and "faster, cheaper, less secure crypto for less sensitive stuff"? I think we've all learned our lesson over the past few decades of watching real applications try to deploy crypto: Options are dangerous. This stuff is complicated enough as it is, and asking callers to choose between a bunch of alphabet soup standards that they don't understand makes things substantially worse. (AES-GCM or AES-ECB?!) It's important to be able to give clear, simple advice: Just use X. So while it's true that most applications aren't bottlenecked by cryptography, pushing the margins of "most" benefits everyone, by putting more weight behind common standards that we know are safe.
- strenholme 5y ago
  If you want to minimize options, and yes, I know corporations with “you will use only these cryptographic algorithms” lists, I would go with SHA-2-256 for cryptographic hashing, [1] AES-192 for encryption, and RSA-2048 for public key. I would phase out RSA-2048 with whatever NIST chooses as their post-Quantium algorithm once that process ends [2], and use SipHash for the special case of choosing which hash bucket to use in hash tables. [3] I would maybe have SHA-3 on standby just in case SHA-2 ever gets broken. [1] SHA-512/256 protects us from key extension attacks, but has much less deployment than SHA-2. We can mandate using SHA-2-256 in HMAC mode when we use it with a secret the attacker does not know. [2] https://csrc.nist.gov/projects/post-quantum-cryptography/workshops-and-timeline https://csrc.nist.gov/projects/post-quantum-cryptography/wor... [3] SHA-2 is called a “hash”, as is “SipHash”, but they are different use cases. SHA-2 is generally for having a long hash where generally both the user and attacker know how to make a given string have a given hash. “SipHash” is to be used for the compression function for a hash table [4] where performance is critical, the hash is shorter, but it is protected by a secret key. [4] https://en.wikipedia.org/wiki/Hash_function https://en.wikipedia.org/wiki/Hash_function [5] If you ask me what my favorite cryptographic hash and stream cipher is, I would say RadioGatún[32]. It has roughly BLAKE2’s speed with the added benefit of enhanced hardware performance. It was the only Extendable-Output Function (XOF) which existed back in 2007—the last time I revised which crypto primitives my own open-source software uses—and remains unbroken as we enter 2022. It know it’s hardly mainstream, but it is Keccak’s direct predecessor, and it has been analyzed by world renowned cryptographers.
strenholme 5y ago
With parameters as specified by SHA3 it's a lot slower than BLAKE3 Keccak (SHA-3) is actually a good deal faster than BLAKE(1) in hardware. That’s the reason why they chose it: It has acceptable performance in software, and very good performance in hardware. KangarooTwelve / MarsupilamiFourteen are Keccak variants with fewer rounds; they should smoke BLAKE2 and probably even BLAKE3 in dedicated hardware. Also, they have tree hashing modes of operation like the later BLAKE developers. The BLAKE family is best in situations where you want the best possible software performance; indeed, there are cases where you do not want hardware to outperform software (e.g. key derivation functions) where some Salsa20/ChaCha20/BLAKE variant makes the most sense. The Keccak family is when one already has dedicated hardware instructions (e.g. ARM already has a hardware level Keccak engine; Intel is dragging their feet but it is only a matter of time) or is willing to trade software performance for more hardware performance. Keccak code is here: https://github.com/XKCP/XKCP https://github.com/XKCP/XKCP
- fabian2k 5y ago
  Is the SHA-3 hardware support already available in existing and widely used hardware?
  - strenholme 5y ago
    Last time I looked, it’s available for ARM but there aren’t Intel ISA SHA-3 instructions yet.
- oconnor663 5y ago
  > they should smoke BLAKE2 and probably even BLAKE3 in dedicated hardware That's certainly possible, but there are subtleties to watch out for. To really take advantage of the tree structure in K12, you need a vectorized implementation of the Keccak permutation. For comparison, there are vectorized implementations of the AES block cipher, and these are very useful for optimizing AES-CTR. This ends up being one of the strengths of CTR mode compared to some other modes like CBC, which can't process multiple blocks in parallel, at least not for a single input. So one subtlety we have to think about, is that the sponge construction inside SHA-3 looks more like CBC mode than like CTR mode. The blocks form a chain. And that means that a vectorized implementation of Keccak can't benefit SHA-3 itself, again at least not for hashing a single input. So if this is going to be provided in hardware, it will have to be specifically with other constructions like K12 in mind. That could happen, but it might be harder to justify the cost in chip area. (At this point I'm out of my depth. I have no idea what Intel or ARM are planning. Or maybe vectorized hardware implementations of Keccak already exist and I'm just writing nonsense.)
floodyberry- 5y ago
> Sure, they're fast (on current hardware), but they're supposed to be cryptographic hash functions. Performance has nothing to do with whether a hash function is "cryptographic" > I know that BLAKE received some scrutiny in this regard BLAKE was one of the most, if not _the_ most, analyzed SHA3 entries. "Keccak received a significant amount of cryptanalysis, although not quite the depth of analysis applied to BLAKE, Grøstl, or Skein" https://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf https://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf > making the claims to security less and less sensible. BLAKE2/3 are not completely new algorithms. They fine tune features from the previous version to be more lightweight while still remaining cryptographically sound > The SHA3 security margin can safely be decreased, as NIST set the security requirements too high. This is one of the reasons for the speed difference. BLAKE and Keccak have roughly equal security margins, which is one reason why BLAKE2/3 can still be secure while being faster than BLAKE. > This means that Blake's security would be less sure even had it received the same level of scrutiny. So since it arguably received more, does that balance things out? Addition being slower in hardware and much more expensive to mask against side channels is a serious argument against ARX constructions, but that isn't really relevant here

by nsajko 5y ago

kortex 5y ago

A) I am not sure I'd say blake2 obsoletes blake, and certainly blake3 does not obsolete b2. They are a family, but still different algorithms. B) blake3, afaik, is not yet as thoroughly vetted as b2. C) I think some of the hype around b3 is deserved. It's crazy fast. If you don't care about crypto at all (e.g. file dedup), it's absolutely phenomenal. But the main downside of B3 right now is just novelty. Cryto algos are like fine wines. D) I don't know enough about Keccak vs Blake, but just because Blake2 has received less scrutiny, doesn't mean it's insufficient. I'm sure there are tradeoffs that the kernel editors have chosen. E: here's a link to some discussion: https://crypto.stackexchange.com/questions/31674/what-advantages-does-keccak-sha-3-have-over-blake2 https://crypto.stackexchange.com/questions/31674/what-advant...

tptacek 5y ago
Blake2 is already in lib/crypto in the kernel (it's needed for WireGuard, by the same author as this change); SHA3 and Blake3 are not. It's probably that simple.
rincebrain 5y ago
BLAKE3 is crazy fast...on x86, with extremely performant implementations using SIMD instructions present. On other platforms, where people haven't written such (or, IME, even on ARM when using their NEON version), it's nothing to write home about.

dlubarov 5y ago

As I understand it, the BLAKE family is built on a tweaked version of the ChaCha cipher, and security is proven under the assumption that this primitive behaves like a random function. Arguably we shouldn't be too concerned that blake3 is new, since ChaCha/Salsa are old primitives whose security has held up well. While the sponge framework is popular, it's rather inflexible, e.g. its sequential structure permits limited parallelism. There are more general sound hashing frameworks that still offer provable security, such as this one which blake3's analysis is based on: https://www.cs.ru.nl/~bmennink/pubs/18fsenew.pdf https://www.cs.ru.nl/~bmennink/pubs/18fsenew.pdf

oconnor663 5y ago

> Sure, they're fast (on current hardware), but they're supposed to be cryptographic hash functions. This is subjective, but in my mind the question of "how important is it for crypto to be fast?" is closely related to the question of "how many crypto options should we give people?" Like, should we design "slower, maximum-security, military-grade crypto for top secret material" and "faster, cheaper, less secure crypto for less sensitive stuff"? I think we've all learned our lesson over the past few decades of watching real applications try to deploy crypto: Options are dangerous. This stuff is complicated enough as it is, and asking callers to choose between a bunch of alphabet soup standards that they don't understand makes things substantially worse. (AES-GCM or AES-ECB?!) It's important to be able to give clear, simple advice: Just use X. So while it's true that most applications aren't bottlenecked by cryptography, pushing the margins of "most" benefits everyone, by putting more weight behind common standards that we know are safe.

strenholme 5y ago
If you want to minimize options, and yes, I know corporations with “you will use only these cryptographic algorithms” lists, I would go with SHA-2-256 for cryptographic hashing, [1] AES-192 for encryption, and RSA-2048 for public key. I would phase out RSA-2048 with whatever NIST chooses as their post-Quantium algorithm once that process ends [2], and use SipHash for the special case of choosing which hash bucket to use in hash tables. [3] I would maybe have SHA-3 on standby just in case SHA-2 ever gets broken. [1] SHA-512/256 protects us from key extension attacks, but has much less deployment than SHA-2. We can mandate using SHA-2-256 in HMAC mode when we use it with a secret the attacker does not know. [2] https://csrc.nist.gov/projects/post-quantum-cryptography/workshops-and-timeline https://csrc.nist.gov/projects/post-quantum-cryptography/wor... [3] SHA-2 is called a “hash”, as is “SipHash”, but they are different use cases. SHA-2 is generally for having a long hash where generally both the user and attacker know how to make a given string have a given hash. “SipHash” is to be used for the compression function for a hash table [4] where performance is critical, the hash is shorter, but it is protected by a secret key. [4] https://en.wikipedia.org/wiki/Hash_function https://en.wikipedia.org/wiki/Hash_function [5] If you ask me what my favorite cryptographic hash and stream cipher is, I would say RadioGatún[32]. It has roughly BLAKE2’s speed with the added benefit of enhanced hardware performance. It was the only Extendable-Output Function (XOF) which existed back in 2007—the last time I revised which crypto primitives my own open-source software uses—and remains unbroken as we enter 2022. It know it’s hardly mainstream, but it is Keccak’s direct predecessor, and it has been analyzed by world renowned cryptographers.

strenholme 5y ago

With parameters as specified by SHA3 it's a lot slower than BLAKE3 Keccak (SHA-3) is actually a good deal faster than BLAKE(1) in hardware. That’s the reason why they chose it: It has acceptable performance in software, and very good performance in hardware. KangarooTwelve / MarsupilamiFourteen are Keccak variants with fewer rounds; they should smoke BLAKE2 and probably even BLAKE3 in dedicated hardware. Also, they have tree hashing modes of operation like the later BLAKE developers. The BLAKE family is best in situations where you want the best possible software performance; indeed, there are cases where you do not want hardware to outperform software (e.g. key derivation functions) where some Salsa20/ChaCha20/BLAKE variant makes the most sense. The Keccak family is when one already has dedicated hardware instructions (e.g. ARM already has a hardware level Keccak engine; Intel is dragging their feet but it is only a matter of time) or is willing to trade software performance for more hardware performance. Keccak code is here: https://github.com/XKCP/XKCP https://github.com/XKCP/XKCP

fabian2k 5y ago
Is the SHA-3 hardware support already available in existing and widely used hardware?
- strenholme 5y ago
  Last time I looked, it’s available for ARM but there aren’t Intel ISA SHA-3 instructions yet.
oconnor663 5y ago
> they should smoke BLAKE2 and probably even BLAKE3 in dedicated hardware That's certainly possible, but there are subtleties to watch out for. To really take advantage of the tree structure in K12, you need a vectorized implementation of the Keccak permutation. For comparison, there are vectorized implementations of the AES block cipher, and these are very useful for optimizing AES-CTR. This ends up being one of the strengths of CTR mode compared to some other modes like CBC, which can't process multiple blocks in parallel, at least not for a single input. So one subtlety we have to think about, is that the sponge construction inside SHA-3 looks more like CBC mode than like CTR mode. The blocks form a chain. And that means that a vectorized implementation of Keccak can't benefit SHA-3 itself, again at least not for hashing a single input. So if this is going to be provided in hardware, it will have to be specifically with other constructions like K12 in mind. That could happen, but it might be harder to justify the cost in chip area. (At this point I'm out of my depth. I have no idea what Intel or ARM are planning. Or maybe vectorized hardware implementations of Keccak already exist and I'm just writing nonsense.)

floodyberry- 5y ago

> Sure, they're fast (on current hardware), but they're supposed to be cryptographic hash functions. Performance has nothing to do with whether a hash function is "cryptographic" > I know that BLAKE received some scrutiny in this regard BLAKE was one of the most, if not _the_ most, analyzed SHA3 entries. "Keccak received a significant amount of cryptanalysis, although not quite the depth of analysis applied to BLAKE, Grøstl, or Skein" https://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf https://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7896.pdf > making the claims to security less and less sensible. BLAKE2/3 are not completely new algorithms. They fine tune features from the previous version to be more lightweight while still remaining cryptographically sound > The SHA3 security margin can safely be decreased, as NIST set the security requirements too high. This is one of the reasons for the speed difference. BLAKE and Keccak have roughly equal security margins, which is one reason why BLAKE2/3 can still be secure while being faster than BLAKE. > This means that Blake's security would be less sure even had it received the same level of scrutiny. So since it arguably received more, does that balance things out? Addition being slower in hardware and much more expensive to mask against side channels is a serious argument against ARX constructions, but that isn't really relevant here