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

141–145 of 145 posts

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

#141

Post by rhengles »

rhengles wrote: post #136
dragontamer wrote: post #64

Earlier quoted context omitted.

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…

I can't edit my post anymore but I found the solution. All I had to do was to convert the random input value (X above) to an uint32 using (X >>> 0).

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

#142

Post by dragontamer »

rhengles wrote: post #141
rhengles wrote: post #136

Earlier quoted context omitted.

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…

I can't edit my post anymore but I found the solution. All I had to do was to convert the random input value (X above) to an uint32 using (X >>> 0).

You did things the hard way by trying to construct the exact inverse.

---------

I suggest the following instead:

1. Create a 16-gigabyte file consisting of f(x) from x=0x00000000 to x=0xFFFFFFFF.

2. Sort the file.

3. Determine that no repeats exist, that is, the values go from 0x00000000 to 0xFFFFFFFF.

--------

Once you have determined that all 32-bit inputs result in all 32-bit outputs, you've determined that the function is invertible. 4-bytes x 2^32 possible inputs == only 16GB these days, small enough to be handled by any old computer... possibly entirely in RAM.

But if you don't got enough RAM for that, an SSD or even Hard Drive would be fast enough for the above procedure. It may take a few minutes but its not that hard.

You see, the goal is to "prove you have an invertible function". At no point do you have to accomplish the difficult task of actually finding the inverse.

-------

Well, I guess if you're "just following the blogpost" about the inverse, maybe that's easier. But from the perspective of "I don't know the inverse yet", its really difficult to figure it out. So you should think about the simpler brute-force methodologies that a modern computer can do in just a few minutes.

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

#143

Post by dr_zoidberg »

jfindley wrote: post #132
orra wrote: post #131

Earlier quoted context omitted.

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 hash…

Yes, I did confused the part about Keccak[0] being "slow" to compute without specfic hardware/extensions with it being slow on GPUs as a design goal.

[0] Taking this as an example of newer crpytographic hashes, rather than the "old ones" that were easier/faster to calculate on GPUs.

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

#145

Post by vagab0nd »

p1mrx wrote: post #93
orangepenguin wrote: post #91

Earlier quoted context omitted.

Ah, yep. You're right. I overlooked that part. It looks like it's truly non-reversible—even if you don't care what the resulting input is.

If you do ever figure out how to reverse SHA-256, best keep it a secret until you've sold all your free Bitcoin.

It's funny, people used to explain that the encryption used in bitcoin is secure because otherwise all your online banking would be at risk.

People don't say that any more because if someone were to break SHA-256 they would actually steal bitcoin first.

Post reply on HN