Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SHA-256 explained step-by-step visually

sha256algorithm.com

Post reply on HN
Print view View original

121–130 of 145 posts

Re: Show HN: SHA-256 explained step-by-step visually

#121

Post by fragmede »

manceraio wrote: post #40
oconnor663 wrote: post #35

Oh this is great. When we taught SHA-256 last semester, we linked to this YouTube video: https://youtu.be/f9EbD6iY9zI . Next time we do it, we'll probably link to both. Having several different ways to visualize the same thing is very helpful, and I like that this one moves quickly. A couple of details missing from this visualization are how you pad a message to be a multiple of the block size, and how you chain bloc…

Thanks for the feedback and I am glad you'll use it for teaching (which was the main goal of this project)! The padding part it's briefly explained on the "dynamic" notes on the left column, but yes, can be improved. Typing on the input gives you some sense of what is doing on the background, specially if it jumps to two blocks. The "for each chunk" is also implemented (which was one of the most difficult parts to sy…

Minor nit: input could also take hex.

Re: Show HN: SHA-256 explained step-by-step visually

#122

Post by Terry_Roll »

bsedlm wrote: post #44
metalrain wrote: post #39

Earlier quoted context omitted.

Visualized like this it feels like security through obscurity, but there must be reason for this. I did wonder why initialization is like: 1. Initialize hash value h0 to h7: first 32 bits of the fractional parts of the square roots of the first 8 primes 2..19). 2. Initialize array of K constants: first 32 bits of the fractional parts of the cube roots of the first 64 primes 2..311

from what I've seen, there's a lot of "obscurity" to this; there are many seemingly arbitrary choices all over the place. In the end most encryption algorithms boil down to doing 'random' (arbitrary, hard to justify why) things to data and then undoing them exactly in order to decrypt. the math is all incredibly abstract but not all that complex, the high level of abstraction does make it quite difficult to grasp. Wh…

> from what I've seen, there's a lot of "obscurity" to this; there are many seemingly arbitrary choices all over the place.

When is a (7-/pk/win)zip compression algo not an encryption algorithm?

Do the use of certain mathematical functions make it an encryption algo?

I've always found the use of prime numbers in some encryption algo's to be a red herring, namely because in theory there are an infinite number of primes, but in practice your computing device can only use 1 from a finite number of primes otherwise it would take too long to encrypt something.

With this in mind, do primes actually make it easier to decrypt encrypted data?

>What's worse is that I fear there are incentives (mostly political/security interests) to keep the field small

Discussions like this ie communication poke light into those dark crevices of intellectuality.

Re: Show HN: SHA-256 explained step-by-step visually

#123

Post by anonymousDan »

I have an odd request regarding e.g. SHA-3. Can anyone tell me if it is implemented in a way that is in a sense 'one-pass' over its input, i.e. each byte of its input in memory is accessed only once, after which all of the algorithm state is held in registers and the original input is never accessed again? My scenario is one where I'm concerned about TOCTOU-like attacks on the memory where the input is stored, but I don't want to pay the overhead of first copying the whole input to a 'safe' memory location, e.g. imagine I have kernel code wanting to compute a hash over data stored in userspace.

Re: Show HN: SHA-256 explained step-by-step visually

#124

Post by oib »

anonymousDan wrote: post #123

I have an odd request regarding e.g. SHA-3. Can anyone tell me if it is implemented in a way that is in a sense 'one-pass' over its input, i.e. each byte of its input in memory is accessed only once, after which all of the algorithm state is held in registers and the original input is never accessed again? My scenario is one where I'm concerned about TOCTOU-like attacks on the memory where the input is stored, but I…

Yes, sha3 reads every input byte only once. It does hold a pretty large internal state that doesn't fit in only registers.

Re: Show HN: SHA-256 explained step-by-step visually

#125

Post by Drdrdrq »

oconnor663 wrote: post #35

Oh this is great. When we taught SHA-256 last semester, we linked to this YouTube video: https://youtu.be/f9EbD6iY9zI . Next time we do it, we'll probably link to both. Having several different ways to visualize the same thing is very helpful, and I like that this one moves quickly. A couple of details missing from this visualization are how you pad a message to be a multiple of the block size, and how you chain bloc…

Thank you for the link to your repo, this it the first time I heard about length extension atracks. TIL, appreciate it! This SO answer explains them nicely, if anyone is curious: https://crypto.stackexchange.com/questions/3978/understandin...

Re: Show HN: SHA-256 explained step-by-step visually

#126

Post by fthtls »

great visualization. i've also checked the source code and utility functions. they are very well defined and useful too.

i've coded a sha256 decrypter recently which uses dictionary attack and brute force. I read lots of articles about sha256 while coding this tool. there were still some missing parts on my mind, but your project clarified all.

btw, the decrypter i coded -> https://10015.io/tools/sha256-encrypt-decrypt

Re: Show HN: SHA-256 explained step-by-step visually

#127

Post by ltfey »

dragontamer wrote: post #103
bsedlm wrote: post #44

Earlier quoted context omitted.

from what I've seen, there's a lot of "obscurity" to this; there are many seemingly arbitrary choices all over the place. In the end most encryption algorithms boil down to doing 'random' (arbitrary, hard to justify why) things to data and then undoing them exactly in order to decrypt. the math is all incredibly abstract but not all that complex, the high level of abstraction does make it quite difficult to grasp. Wh…

> What's worse is that I fear there are incentives (mostly political/security interests) to keep the field small and to keep many people far away from this very practical use for all these beautiful, elegant, simple (but extremely abstract) mathematics (refering to the entire cryptography field). I mean, everything you want to learn about crypto is available online, in libraries, in textbooks. Including differential…

What has happened is that the "old generation" of programmers is dying out / retiring. And they aren't passing on their knowledge to the new generation. The "old generation" of programmers were high-math, abstract algebra and more, while "new generation" programmers just never bothered to learn this stuff.

There may be some survivorship bias here. Even in the 1990s, business-grade programmers (the ones who, quite frankly, aren't inclined to learn difficult subjects) either went into management or did something else, although the timeframe and ageism are more aggressive these days due to the infantilization and humiliation (e.g., Agile Scrum) that engineers face today.

Research-grade programmers were the minority, even then, although this problem is a lot worse today due to the near nonexistence of R&D jobs.

Re: Show HN: SHA-256 explained step-by-step visually

#128

Post by can16358p »

breakingcups wrote: post #27
can16358p wrote: post #24

Earlier quoted context omitted.

If such a movie even mentions SHA-256 I think that's above average on its own.

That depends.. "Just a second, I need to backdoor the SHA256 rootkit to penetrate the directory. Shit, they have an X62 firewall. Luckily I brought my pentester."

You're right. Still, mentioning SHA-256 brings better possibility of "someone knowing something", compared to, say, GUI, Visual Basic, and tracing IP addresses.

Re: Show HN: SHA-256 explained step-by-step visually

#129

Post by Dowwie »

oconnor663 wrote: post #35

Oh this is great. When we taught SHA-256 last semester, we linked to this YouTube video: https://youtu.be/f9EbD6iY9zI . Next time we do it, we'll probably link to both. Having several different ways to visualize the same thing is very helpful, and I like that this one moves quickly. A couple of details missing from this visualization are how you pad a message to be a multiple of the block size, and how you chain bloc…

What course did you teach?! Have you got a syllabus?

Re: Show HN: SHA-256 explained step-by-step visually

#130

Post by dr_zoidberg »

floodyberry- wrote: post #67
picture wrote: post #36

So, how do people come up with these things? I assume every aspect of the design is carefully considered to defend it against various attacks. For example, why "right rotate 7 XOR right rotate 18 XOR right shift 3" and not "right rotate 2 XOR right rotate 3 XOR right shift 4"?

Generally, come up with a set of operations that you want to use that meet your design criteria (fast in hardware, fast in software, fast in SIMD, whatever), then brute-force the instruction order and/or arbitrary constants (rotations) to minimize known attacks and maximize diffusion e.g. the Chacha20 design document explains the choices made in a fairly high level and easy to understand way: https://cr.yp.to/chacha/…

> (fast in hardware, fast in software, fast in SIMD, whatever)

"Slow to compute in GPUs" has been another design criterion for a while. It helps against brute force attacks. Of course, you might want your hash to be fast on GPUs too, if you're trying to accelerate something, bu cryptographic hashes usually aim for attack resistance.

Post reply on HN