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

131–140 of 145 posts

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

#131

Post by orra »

dr_zoidberg wrote: post #130
floodyberry- wrote: post #67

Earlier quoted context omitted.

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.

I’m surprised that’s a design crtieria. Being able to calculate hashes quickly is advantageous.

Speeding up hashing by, what, a few orders of magnitude shouldn’t break your ≥ 128 bits of preimage protection, surely?

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

#132

Post by jfindley »

orra wrote: post #131
dr_zoidberg wrote: post #130

Earlier quoted context omitted.

> (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.

I’m surprised that’s a design crtieria. Being able to calculate hashes quickly is advantageous. Speeding up hashing by, what, a few orders of magnitude shouldn’t break your ≥ 128 bits of preimage protection, surely?

It depends what the goal of your hashing function is. Pure cryptographic hashes like sha256 want to be cheap to calculate. Slow on GPUs is only a design goal if you're making a password hash function, which is a rather different class of problem to sha256/chacha20 and similar.

I think the commenter you're responding to got a little confused somewhere along the way and conflated cryptographic hashes with password hashing.

EDIT: To be clear, password hashes are also cryptographic hashes - but they're a specific subclass of crypto hashes with different design criteria.

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

#133

Post by MontagFTB »

orra wrote: post #131
dr_zoidberg wrote: post #130

Earlier quoted context omitted.

> (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.

I’m surprised that’s a design crtieria. Being able to calculate hashes quickly is advantageous. Speeding up hashing by, what, a few orders of magnitude shouldn’t break your ≥ 128 bits of preimage protection, surely?

This is a known technique for password hash protection too. By limiting the usefulness of the GPU, you shield yourself from high speed password crackers in the event your password database is compromised.

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

#135

Post by oconnor663 »

Dowwie wrote: post #129
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?

Applied Cryptography (CS-GY 6903) at NYU Tandon. You can find all our programming problem sets in the same repo: https://github.com/oconnor663/applied_crypto_2021_fall.

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

#136

Post by rhengles »

dragontamer wrote: post #64
manceraio wrote: post #62

Earlier quoted context omitted.

Do you recommend any resources to learn about this?

The information in the above post is a merger of like, 20 different sources of information. Your standard cryptographic books from any undergraduate program will tell you about the basics of confusion / diffusion, but I don't think the concept is very difficult at all. Invertibility is hugely important but not discussed very much. It seems like crypto-experts 'obviously' know about it so they just don't talk about it…

Forgive me for replying here, I couldn't find an option to DM you. And I cannot find any implementation of this in javascript, nor anyone else able to help me.

Can you shed some light here why I'm getting these differences?

https://jsfiddle.net/7kf15dje/

Here is an example of the output I'm getting:

  //       X  A  B           X^1         X^-1 :: Difference
   471490377  6 13 =  1365552781 =  471490377 :: 0
  1528396978  9 11 = -1576695076 = 1528396978 :: -0
  1592322722  9 20 =   622346385 = 1592322722 :: -0
  1214152986  8 16 = -1748578289 = 1214152985 :: -1
  1193897367  2 16 =   907713766 = 1193897366 :: -1
   335642564  9 10 =   318891964 =  335642564 :: -0
   486208953 16 23 =   894211128 =  486208952 :: -1
   629577059 13 14 =  1383225523 =  629577058 :: -1
  1609442937  8 18 =   674046110 = 1609442937 :: -0
   234450967  6 12 =  -459008694 =  234450966 :: -1
  1840721644 19 28 =  -602984005 = 1840721644 :: -0

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

#137

Post by tptacek »

dr_zoidberg wrote: post #130
floodyberry- wrote: post #67

Earlier quoted context omitted.

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.

No, no, no. That's a criteria for password hashes, which are a totally different construction than standard cryptographic hashes. You can't brute force a cryptographic hash, practically by definition.

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

#138

Post by dr_zoidberg »

tptacek wrote: post #137
dr_zoidberg wrote: post #130

Earlier quoted context omitted.

> (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.

No, no, no. That's a criteria for password hashes , which are a totally different construction than standard cryptographic hashes. You can't brute force a cryptographic hash, practically by definition.

I must have conflated Keccak's "slow without specific hardware/extensions" with "slow on purpose against GPUs". Both are similar (why would a GPU have an operation for cryptography?) but obviously not the same thing.

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

#140

Post by dllthomas »

tptacek wrote: post #137
dr_zoidberg wrote: post #130

Earlier quoted context omitted.

> (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.

No, no, no. That's a criteria for password hashes , which are a totally different construction than standard cryptographic hashes. You can't brute force a cryptographic hash, practically by definition.

The distinction being the relatively small space of possible preimages?
Post reply on HN