How SHA-256 Works Step-by-Step • Hacker News Board

Re: How SHA-256 Works Step-by-Step

#51

Post by pvg » Sun, Apr 24, 2022, 2:05 PM UTC

greggsy wrote: post #18

pvg wrote: post #4

Earlier quoted context omitted.

You're better off reading the Wikipedia page which covers things like that (for instance, the Merkle–Damgård construction) in some detail and without all the oversimplifications and almost unavoidable wrongness of slight write-ups like this.

On the contrary, I just want the dumbed down version. I’m not ever going to implement it ( nobody should RYO crypto unless you really know what you’re doing), nor am I going to have to rely on the knowledge in my daily life - I’m not a maths educator, and I’m certainly not a cryptographer. It’s still good to understand the basics. I learnt a lot about PKI by forcing myself to learn the absolute basics of modulo, but…

This isn't really a 'dumbed down version' and the person I'm replying to specifically asked about the sort of things not covered in this version.

Re: How SHA-256 Works Step-by-Step

#52

Post by can16358p » Sun, Apr 24, 2022, 2:56 PM UTC

edflsafoiewq wrote: post #29

can16358p wrote: post #25

Earlier quoted context omitted.

Came here to ask the same. I enjoyed the blog, yet as a non-cryptographer, I'd like to see the reasons behind the actions: e.g. Okay we right rotate that input, but why are we doing this? Or Why are we taking cube roots of 64 primes? etc.

> Why are we taking cube roots of 64 primes? https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number

That was helpful. It'd be great if there are tips like these (even Wikipedia links like this is very helpful) are also present in the posts like the blog post.

Re: How SHA-256 Works Step-by-Step

#53

Post by Dylan16807 » Sun, Apr 24, 2022, 9:05 PM UTC

tialaramex wrote: post #50

Dylan16807 wrote: post #47

Earlier quoted context omitted.

If you had no size based padding, you could fake a document having a few more zero bytes at the end. That's almost never dangerous, and it also requires very specific (mis)use to cause problems, just like a length extension. Unless you can name a killer use case, I stand by length extension problems being a significantly bigger deal and more "necessary" to stop. > You're supposed to be able to remove the padding in c…

> Unless you can name a killer use case, I stand by length extension problems being a significantly bigger deal and more "necessary" to stop. "it works as a cryptographic hash" is certainly a "killer use case" for a cryptographic hash. Your "Dylan16807 hash" without working padding does not work as a cryptographic hash, it's useless.

It would work just fine. And if you call those messages equivalent then there is no cryptographic failing. You'll need better than that argument.

Nobody complains that RSA gives you the same result for 45 and 0045 after all.

Better, think of it like a hash algorithm that takes bits vs one that takes bytes. They both work fine and are secure. If your byte happens to be a really wide byte, that's not a fatal flaw.

Re: How SHA-256 Works Step-by-Step

#54

Post by Arnt » Mon, Apr 25, 2022, 10:10 AM UTC

emerged wrote: post #2

Every time one of these is posted, I’m expecting the steps to explain why they are being done. Like what makes this combination of operations have the particular properties we need?

AOL. It's like the articles that would explain how unix software by explaining in detail how to ./configured;make;make install and leave out everything specific to the software in question.

I can explain one small part, though. A lot of these things need some fixed constants that have to be not all-zero, not all-one, not easily predictable and not someone's backdoor. So people will say things like "we need five ten-digit numbers here, so we'll use the second to eleventh digits of the square roots of the first five primes".

That is, the use of the square root has nothing to do with being the square root of two, there's no deep math. The square root of two is just some number that you won't suspect of being a backdoor.

https://en.wikipedia.org/wiki/Nothing-up-my-sleeve_number

Re: How SHA-256 Works Step-by-Step

#55

Post by tialaramex » Mon, Apr 25, 2022, 6:14 PM UTC

Dylan16807 wrote: post #53

tialaramex wrote: post #50

Earlier quoted context omitted.

> Unless you can name a killer use case, I stand by length extension problems being a significantly bigger deal and more "necessary" to stop. "it works as a cryptographic hash" is certainly a "killer use case" for a cryptographic hash. Your "Dylan16807 hash" without working padding does not work as a cryptographic hash, it's useless.

It would work just fine. And if you call those messages equivalent then there is no cryptographic failing. You'll need better than that argument. Nobody complains that RSA gives you the same result for 45 and 0045 after all. Better, think of it like a hash algorithm that takes bits vs one that takes bytes. They both work fine and are secure. If your byte happens to be a really wide byte, that's not a fatal flaw.

> And if you call those messages equivalent then there is no cryptographic failing. You'll need better than that argument.

Defining failure as success is very, very stupid. Nobody needs to "do better" than calling your position out as wrong.

> Nobody complains that RSA gives you the same result for 45 and 0045 after all.

RSA doesn't give you "the same result for 45 and 0045" unless what you mean by "0045" is "Actually just 45 except for some reason I write that with extra zeroes as part of my bad faith argument".

Hash algorithms that don't work aren't "just fine" they're useless.

The reason algorithms like SHA-256 are defined for bits isn't arbitrary - bits are literally the unit of information, this is the obvious and natural way to define the function, so choosing to define a function over "really wide bytes" doesn't make any sense.

Re: How SHA-256 Works Step-by-Step

#56

Post by Dylan16807 » Tue, Apr 26, 2022, 2:09 AM UTC

tialaramex wrote: post #55

Dylan16807 wrote: post #53

Earlier quoted context omitted.

It would work just fine. And if you call those messages equivalent then there is no cryptographic failing. You'll need better than that argument. Nobody complains that RSA gives you the same result for 45 and 0045 after all. Better, think of it like a hash algorithm that takes bits vs one that takes bytes. They both work fine and are secure. If your byte happens to be a really wide byte, that's not a fatal flaw.

> And if you call those messages equivalent then there is no cryptographic failing. You'll need better than that argument. Defining failure as success is very, very stupid. Nobody needs to "do better" than calling your position out as wrong. > Nobody complains that RSA gives you the same result for 45 and 0045 after all. RSA doesn't give you "the same result for 45 and 0045" unless what you mean by "0045" is "Actuall…

> Nobody needs to "do better" than calling your position out as wrong.

It's not going to be convincing unless you can talk about a specific attack. And in particular, that attack should be more relevant to real-world use than a weakness like length extension.

Especially because you could look at this weakness as a sibling attack to length extension, one that's mildly easier to pull off but you can only append zeros. That seems safer overall to me. And it's not reasonable to completely excuse one flaw as needing "misuse" but not the other.

> The reason algorithms like SHA-256 are defined for bits isn't arbitrary - bits are literally the unit of information, this is the obvious and natural way to define the function, so choosing to define a function over "really wide bytes" doesn't make any sense.

A hash algorithm that takes an input in bytes is not a failure. If you think taking single bits is actually necessary, rather than just 'obvious and natural', then I really think you're not analyzing the security properly.