6 ms·

Can someone who knows crypto shed some light on the "gravity" of this algorithm? Is this going to out and out replace MD5, or will it fall among the many "aweso

Can someone who knows crypto shed some light on the "gravity" of this algorithm? Is this going to out and out replace MD5, or will it fall among the many "awesome, but not widely used" hashes out there? It sounds pretty awesome... almost too awesome!

borando 13y ago
With serious protocol designers now largely side-stepping the IETF due to BULLRUN infiltration, BLAKE2 and other non-standard primitives have a better shot than before of seeing mass adoption. I hope to see BLAKE2 widely used in the future. I also hope to see more non-standard crypto and protocols, where "the market" leads the way, and standards groups try to keep up in order to appear legitimate.
- tptacek 13y ago
  The IETF doesn't standardize cryptography. If you think Joan Daemen is an NSA plant, you've got bigger problems than hash functions.
  - borando 13y ago
    Maybe we're using different definitions of standardization. The IETF writes RFCs which developers are expected to follow, and (mostly) do. This is a standardization of sorts, but it's beside the point I was making. I'm not talking about Joan Daemen wrt BULLRUN. I'm referring to secure protocols that offer RC4 but not Salsa20, TLS without a single constant time cipher, 112-bit security, secure protocols that aren't even encrypted, null ciphers, Dragonfly, cipher suites so complex that they're expected to be implemented wrongly, secure protocols made so complex they won't be used at all, crypto advisory groups run by NSA employees, etc.
    - tptacek 13y ago
      TLS offers RC4 and not Salsa20 because RC4 existed when SSL was first defined by Netscape, and Salsa20 didn't, and wouldn't for over a decade. It's worth mentioning here that the "encrypted by default" Internet that was the dream of the 1990s was a government project, and TLS more or less thwarted it. Different ciphers can be more or less straightforward to implement without timing leaks, but "constant time" is a property of an implementation, not of a cipher. Dragonfly is exceedingly lame, but it's also completely inside-baseball. Even if Dragonfly had been "standardized" by the TLS WG, nobody ever would have used it, because nobody ever used SRP either, and SRP was better. The ciphersuites in TLS aren't complicated. They're very simple. The problem with TLS ciphersuites isn't that they're complicated but that they're wrong. Which is unsurprising, because they were designed before anything like Bellare and Namprempre; in fact, they were designed in an era where many practitioners believed that message authentication was unnecessary for cryptosystems at all. I'm not sure which complex secure protocols you're referring to. TLS and SSH are so widely used it seems fair to call them universal. As for the CFRG chair, well, I won't repeat myself: https://news.ycombinator.com/item?id=6942145 https://news.ycombinator.com/item?id=6942145 In the end, though, the real issue I have with your comment is that the IETF has nothing at all to do with BLAKE2's standards- friendliness. The IETF will soon standardize ChaCha20-Poly1305 for TLS, for instance, despite the fact that no NIST standard will ever do the same.
- mpyne 13y ago
  > I also hope to see more non-standard crypto and protocols, where "the market" leads the way This is super-dangerous, unless the amorphous "market" is also paying for cryptanalysts to bang on the crypto primitives as a public service to all competitors in the market. After all, RSA adopting Dual EC DRBG was a business decision, and one which the market didn't reverse despite Dual EC DRBG being publically known to have a probable backdoor since 2007.
tptacek 13y ago
MD5 has already been out-and-out replaced. For applications that require collision resistance, MD5 is already dangerous. Even in a setting where MD5 is unlikely to cause real problems, like in an HMAC authenticator, its use would still be flagged in an audit. No competent new design in 2014 would use SHA1 either. In the world we live in now, there are two "mainstream" options for hash functions: SHA2 (ie, SHA2/256, SHA2/512, &c) and SHA3. SHA3 is actually not at all mainstream (very few applications use it), but (a) that will change over time and (b) nobody will really bat an eyelid if you choose to use it. What Zooko is advocating for is a third mainstream option: BLAKE2. BLAKE2 is derived from a well-regarded SHA3 finalist; the preponderance of evidence suggests that BLAKE2 is safe, and arguably a more conservative choice than SHA3 (a/k/a Keccak, pronounced "Ketchup"), because SHA3's novel sponge function design hasn't been banged on the way SHA2's design, which BLAKE sort of shares, has. The reality is that for most software designers, this isn't an important issue; most software isn't constrained by the speed of its hashing algorithms (the common bottleneck in crypto code is the bignum work public key algorithms have to do --- if you're worried about bottlenecked on hashing, you probably have a much bigger problem with I/O).
- dfc 13y ago
  I was wondering how the new "optional parallel mode" affects the long history of professional scrutiny. Is adding an optional parallel mode something that a professional cryptographer can do without significantly changing the security model?[^1] Are there certain families of hash designs amenable slight tweaks that sacrifice a little security for a relatively large speed improvement or is this something that could happen with the majority of hash schemes? As always, thanks for playing "HN asks tptacek about security." [^1]: This is a genuine question. I do not have any reason to doubt zooko et al's judgement. I guess another way of saying this is "For someone smarter than me is it easy to know when this is a good/bad idea?" Strange segway: I was browsing Plos and saw this article about egg washing and shell characteristics. After reading the title for some reason I remembered reading a somewhat lengthy comment you wrote about the safety of eggs and different egg washing regimes in the us and the uk. I did not check too see if my recollection was accurate but in case it is and the comment was indicative of your interest in the subject you might get a kick out of: Effect of Egg Washing and Correlation between Eggshell Characteristics and Egg Penetration by Various Salmonella Typhimurium Strains. PLoS ONE 9(3): e90987. doi:10.1371/journal.pone.0090987 http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0090987 http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...

borando 13y ago

With serious protocol designers now largely side-stepping the IETF due to BULLRUN infiltration, BLAKE2 and other non-standard primitives have a better shot than before of seeing mass adoption. I hope to see BLAKE2 widely used in the future. I also hope to see more non-standard crypto and protocols, where "the market" leads the way, and standards groups try to keep up in order to appear legitimate.

tptacek 13y ago
The IETF doesn't standardize cryptography. If you think Joan Daemen is an NSA plant, you've got bigger problems than hash functions.
- borando 13y ago
  Maybe we're using different definitions of standardization. The IETF writes RFCs which developers are expected to follow, and (mostly) do. This is a standardization of sorts, but it's beside the point I was making. I'm not talking about Joan Daemen wrt BULLRUN. I'm referring to secure protocols that offer RC4 but not Salsa20, TLS without a single constant time cipher, 112-bit security, secure protocols that aren't even encrypted, null ciphers, Dragonfly, cipher suites so complex that they're expected to be implemented wrongly, secure protocols made so complex they won't be used at all, crypto advisory groups run by NSA employees, etc.
  - tptacek 13y ago
    TLS offers RC4 and not Salsa20 because RC4 existed when SSL was first defined by Netscape, and Salsa20 didn't, and wouldn't for over a decade. It's worth mentioning here that the "encrypted by default" Internet that was the dream of the 1990s was a government project, and TLS more or less thwarted it. Different ciphers can be more or less straightforward to implement without timing leaks, but "constant time" is a property of an implementation, not of a cipher. Dragonfly is exceedingly lame, but it's also completely inside-baseball. Even if Dragonfly had been "standardized" by the TLS WG, nobody ever would have used it, because nobody ever used SRP either, and SRP was better. The ciphersuites in TLS aren't complicated. They're very simple. The problem with TLS ciphersuites isn't that they're complicated but that they're wrong. Which is unsurprising, because they were designed before anything like Bellare and Namprempre; in fact, they were designed in an era where many practitioners believed that message authentication was unnecessary for cryptosystems at all. I'm not sure which complex secure protocols you're referring to. TLS and SSH are so widely used it seems fair to call them universal. As for the CFRG chair, well, I won't repeat myself: https://news.ycombinator.com/item?id=6942145 https://news.ycombinator.com/item?id=6942145 In the end, though, the real issue I have with your comment is that the IETF has nothing at all to do with BLAKE2's standards- friendliness. The IETF will soon standardize ChaCha20-Poly1305 for TLS, for instance, despite the fact that no NIST standard will ever do the same.
mpyne 13y ago
> I also hope to see more non-standard crypto and protocols, where "the market" leads the way This is super-dangerous, unless the amorphous "market" is also paying for cryptanalysts to bang on the crypto primitives as a public service to all competitors in the market. After all, RSA adopting Dual EC DRBG was a business decision, and one which the market didn't reverse despite Dual EC DRBG being publically known to have a probable backdoor since 2007.

tptacek 13y ago

MD5 has already been out-and-out replaced. For applications that require collision resistance, MD5 is already dangerous. Even in a setting where MD5 is unlikely to cause real problems, like in an HMAC authenticator, its use would still be flagged in an audit. No competent new design in 2014 would use SHA1 either. In the world we live in now, there are two "mainstream" options for hash functions: SHA2 (ie, SHA2/256, SHA2/512, &c) and SHA3. SHA3 is actually not at all mainstream (very few applications use it), but (a) that will change over time and (b) nobody will really bat an eyelid if you choose to use it. What Zooko is advocating for is a third mainstream option: BLAKE2. BLAKE2 is derived from a well-regarded SHA3 finalist; the preponderance of evidence suggests that BLAKE2 is safe, and arguably a more conservative choice than SHA3 (a/k/a Keccak, pronounced "Ketchup"), because SHA3's novel sponge function design hasn't been banged on the way SHA2's design, which BLAKE sort of shares, has. The reality is that for most software designers, this isn't an important issue; most software isn't constrained by the speed of its hashing algorithms (the common bottleneck in crypto code is the bignum work public key algorithms have to do --- if you're worried about bottlenecked on hashing, you probably have a much bigger problem with I/O).

dfc 13y ago
I was wondering how the new "optional parallel mode" affects the long history of professional scrutiny. Is adding an optional parallel mode something that a professional cryptographer can do without significantly changing the security model?[^1] Are there certain families of hash designs amenable slight tweaks that sacrifice a little security for a relatively large speed improvement or is this something that could happen with the majority of hash schemes? As always, thanks for playing "HN asks tptacek about security." [^1]: This is a genuine question. I do not have any reason to doubt zooko et al's judgement. I guess another way of saying this is "For someone smarter than me is it easy to know when this is a good/bad idea?" Strange segway: I was browsing Plos and saw this article about egg washing and shell characteristics. After reading the title for some reason I remembered reading a somewhat lengthy comment you wrote about the safety of eggs and different egg washing regimes in the us and the uk. I did not check too see if my recollection was accurate but in case it is and the comment was indicative of your interest in the subject you might get a kick out of: Effect of Egg Washing and Correlation between Eggshell Characteristics and Egg Penetration by Various Salmonella Typhimurium Strains. PLoS ONE 9(3): e90987. doi:10.1371/journal.pone.0090987 http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjournal.pone.0090987 http://www.plosone.org/article/info%3Adoi%2F10.1371%2Fjourna...