3 ms·

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 suf

by 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?
    - a1369209993 4y ago
      A bit late myself, but to clarify: Making late (in this case, after the competition was already over) changes to a crytographic primitive - without extensive documentation both of why that's necessary (not just helpful) and why it's not possible (not just you promise it doesn't) for that to weaken security or insert backdoors - is a act of either bad faith or sufficiently gross incompetence that it should be considered de facto bad faith. Schneier claiming to believe that it's good faith implies that he either doesn't understand or (presumably more likely given his history?) doesn't care about keeping the standardization process secure against corruption by the NSA, which suggests either incompetence or bad faith on Schneier's part as well. (Or, in context, that someone was leaning on him after the earlier criticism.) This is particularly inexcusable since reducing security parameters on the pretense that "56 bits ought to be enough for anybody" is a known NSA tactic dating back to fucking DES.
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.

by aliqot 4y ago

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?
  - a1369209993 4y ago
    A bit late myself, but to clarify: Making late (in this case, after the competition was already over) changes to a crytographic primitive - without extensive documentation both of why that's necessary (not just helpful) and why it's not possible (not just you promise it doesn't) for that to weaken security or insert backdoors - is a act of either bad faith or sufficiently gross incompetence that it should be considered de facto bad faith. Schneier claiming to believe that it's good faith implies that he either doesn't understand or (presumably more likely given his history?) doesn't care about keeping the standardization process secure against corruption by the NSA, which suggests either incompetence or bad faith on Schneier's part as well. (Or, in context, that someone was leaning on him after the earlier criticism.) This is particularly inexcusable since reducing security parameters on the pretense that "56 bits ought to be enough for anybody" is a known NSA tactic dating back to fucking DES.

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.