61–70 of 75 posts
From the paper, this doesn't seem to be able to create a collision while retaining the same length of input data. It seems that checking both the hash and input length would be a very cheap way of identifying attempts at hash collisions.
Can collision attacks provide the same size of data? I suspect it would be dramatically more difficult to produce a collision of equal data-size as the original. So perhaps, the easiest way to defend against a collision attack is to transmit the size of the data alongside the checksum. Like a checksum, it is extremely lightweight and easy to check. In my data framework project (where I use sha1 to identify blocks), I…
In all the attacks on MD5 or SHA-1 I'm aware of, the generated colliding strings had the same length.
Earlier quoted context omitted.
Catalin was quoting me in the article, so it's only fair that I elaborate here. There are four common flavors of the SHA2 family you're likely to run into: - SHA-224 - SHA-256 - SHA-384 - SHA-512 And then there are two more variants of "truncated SHA-512" (except they also use different initialization vectors than SHA-512, which is kind of an important detail) - SHA-512/256 - SHA-512/224 These latter two don't have n…
> I think BLAKE2 is going to become the de jure SHA2 successor at least until SHA3 hardware acceleration becomes ubiquitous. I think you mean "de facto", unless you think NIST is going to amend SHA-3 at this point to designate BLAKE over Keccak. As someone on the sidelines, having read the linked Twitter discussion you had with Marc Stevens your summary of it honestly seems a bit disingenuous. You mention speed promi…
The reason this "logical conclusion" sounds so absurd is that your reasoning here is absurd.
What matters isn't "cryptanalysts haven't published an attack", what matters is "cryptanalysts tried and failed to attack the design".
If you conflate the two, you will end up confused.
Earlier quoted context omitted.
Catalin was quoting me in the article, so it's only fair that I elaborate here. There are four common flavors of the SHA2 family you're likely to run into: - SHA-224 - SHA-256 - SHA-384 - SHA-512 And then there are two more variants of "truncated SHA-512" (except they also use different initialization vectors than SHA-512, which is kind of an important detail) - SHA-512/256 - SHA-512/224 These latter two don't have n…
I'm one of the co-author of the SHA-1 cryptanalysis paper. I fully agree with Marc Stevens's: you should not be using Blake2, but SHA2 or SHA3. If speed is an issue, taking reduced step SHA3 (KangarooTwelve) will do the job.
To be clear: I agree with Marc in general, but there are exceptions where I disagree with Marc's "only use {FIPS,NIST,etc.}-approved crypto":
* I prefer Ed25519 over foot-bullety ECDSA (i.e. before RFC 6979).
* I prefer to never use RSA at all.
* I prefer XChaCha20-Poly1305 over AES-GCM, since the former is always constant-time without requiring specialized hardware and you have a negligible chance of nonce misuse even after an absurd number of messages.
* I prefer Argon2id and scrypt over PBKDF2 for key stretching.
* I prefer Argon2id and bcrypt over PBKDF2 for password storage.
* I prefer BLAKE2 over SHA-256, especially when length extension attacks are within the threat model of the protocol being discussed. SHA3 is good. Most SHA2 hash functions are fine (as long as they're not being used stupidly). But BLAKE2 is not only faster, thanks to libsodium, it's more readily available to developers than SHA3 (which, like AES, is only performant with specialized hardware circuits in software that takes advantage of said circuits).
None of the algorithms I've mentioned above are random pet projects by hobbyists.
To resolve this impasse, what needs to happen is: Standards bodies (NIST, FIPS, ISO, etc.) need to stop digging their heels in on sunk-cost fallacies and give at least some of these algorithms a fair consideration. Then one of two things will follow:
1. They'll be found to be as secure as the cryptographers who have studied them already believe, and therefore appropriate for standardization.
2. New attacks will be found, and the state of the art can be moved forward.
And this trend of cryptography towards requiring specialized hardware to be fast and secure? I oppose it wholeheartedly.
Earlier quoted context omitted.
> I think BLAKE2 is going to become the de jure SHA2 successor at least until SHA3 hardware acceleration becomes ubiquitous. I think you mean "de facto", unless you think NIST is going to amend SHA-3 at this point to designate BLAKE over Keccak. As someone on the sidelines, having read the linked Twitter discussion you had with Marc Stevens your summary of it honestly seems a bit disingenuous. You mention speed promi…
> The absurd logical conclusion of that criteria taken at face value is that we'd all be better off if we each used our own bespoke hash function, since cryptanalysis would never be able to keep up. The reason this "logical conclusion" sounds so absurd is that your reasoning here is absurd. What matters isn't "cryptanalysts haven't published an attack", what matters is "cryptanalysts tried and failed to attack the de…
Obviously I'm not saying that BLAKE hasn't gotten any analysis. It was a SHA-3 finalist, it's been looked at by a lot of smart people.
I am saying it's a continuum, and it's safe to assume SHA-2 has gotten a lot more eyeballs & man hours by now. Both due to its age, and due to its widespread production use as a NIST standard.
Is that a trite point? Yes, but one you managed to omit in your long summary of a Twitter exchange with a SHA-1 researcher, which is why I'm pointing it out. You're seemingly treating "analyzed" as a boolean property.
Earlier quoted context omitted.
> The absurd logical conclusion of that criteria taken at face value is that we'd all be better off if we each used our own bespoke hash function, since cryptanalysis would never be able to keep up. The reason this "logical conclusion" sounds so absurd is that your reasoning here is absurd. What matters isn't "cryptanalysts haven't published an attack", what matters is "cryptanalysts tried and failed to attack the de…
A reductio ad absurdum is always going to be absurd if taken at face value, but that doesn't mean the underlying point it's making isn't valid. Obviously I'm not saying that BLAKE hasn't gotten any analysis. It was a SHA-3 finalist, it's been looked at by a lot of smart people. I am saying it's a continuum, and it's safe to assume SHA-2 has gotten a lot more eyeballs & man hours by now. Both due to its age, and due t…
The next question I would ask myself in this context is, "Should I have even raised the trite point in the first place?"
Earlier quoted context omitted.
A reductio ad absurdum is always going to be absurd if taken at face value, but that doesn't mean the underlying point it's making isn't valid. Obviously I'm not saying that BLAKE hasn't gotten any analysis. It was a SHA-3 finalist, it's been looked at by a lot of smart people. I am saying it's a continuum, and it's safe to assume SHA-2 has gotten a lot more eyeballs & man hours by now. Both due to its age, and due t…
> Is that a trite point? Yes The next question I would ask myself in this context is, "Should I have even raised the trite point in the first place?"
It's clear from anyone who reads that Twitter discussion that the thrust of Marc's point is not that we should be "reinforcing public trust in standards". To summarize the discussion in those terms amounts to attacking a strawman.
Earlier quoted context omitted.
> Is that a trite point? Yes The next question I would ask myself in this context is, "Should I have even raised the trite point in the first place?"
It's trite because it should go without saying, but one you managed to selectively omit when summarizing a Twitter discussion. That makes you seem disingenuous. It's clear from anyone who reads that Twitter discussion that the thrust of Marc's point is not that we should be "reinforcing public trust in standards". To summarize the discussion in those terms amounts to attacking a strawman.
It isn't?
https://twitter.com/realhashbreaker/status/11283305376455639...
https://twitter.com/realhashbreaker/status/11283322027758632...
https://twitter.com/realhashbreaker/status/11283784887324385...
"Marc Stevens wants to reinforce the public trust in standards, especially among non-experts" isn't an uncharitable summary of this conversation.
> That makes you seem disingenuous.
If I'm mistaken about the point he's defending, it's not an act of dishonesty.
Given that he at multiple points agreed with my arguments that standards bodies make dumb mistakes and yet continued to double down on "we should just follow standards anyway" without caveat, there aren't many alternative interpretations that I'm aware of.
If I still seem disingenuous, it might be that you want me to seem that way. In which case, there's no point in either of us continuing to participate because it has ceased to be about security and instead has become a discussion of ego, which I'm frankly uninterested in.
Earlier quoted context omitted.
It's trite because it should go without saying, but one you managed to selectively omit when summarizing a Twitter discussion. That makes you seem disingenuous. It's clear from anyone who reads that Twitter discussion that the thrust of Marc's point is not that we should be "reinforcing public trust in standards". To summarize the discussion in those terms amounts to attacking a strawman.
> the thrust of Marc's point is not that we should be "reinforcing public trust in standards" It isn't? https://twitter.com/realhashbreaker/status/11283305376455639... https://twitter.com/realhashbreaker/status/11283322027758632... https://twitter.com/realhashbreaker/status/11283784887324385... "Marc Stevens wants to reinforce the public trust in standards, especially among non-experts" isn't an uncharitable summary…
But my point was not "just follow standards anyway". This tweet clearly shows that: https://twitter.com/realhashbreaker/status/11283830292552581...
Rather that it is better to promote to work through standards as a community as opposed to your way of where individuals promote their pet primitives. Standards serve a role as a focal point: the benefit of being big targets, getting a lot of scrutiny and easier for non-experts to find out if somebody found security issues.
Earlier quoted context omitted.
> the thrust of Marc's point is not that we should be "reinforcing public trust in standards" It isn't? https://twitter.com/realhashbreaker/status/11283305376455639... https://twitter.com/realhashbreaker/status/11283322027758632... https://twitter.com/realhashbreaker/status/11283784887324385... "Marc Stevens wants to reinforce the public trust in standards, especially among non-experts" isn't an uncharitable summary…
Actually, I did add caveats and do recognize that not all standards are equally important. In the tweets you link I'm talking about secure standards, as in standards that are actually considered secure. But my point was not "just follow standards anyway". This tweet clearly shows that: https://twitter.com/realhashbreaker/status/11283830292552581... Rather that it is better to promote to work through standards as a co…