LoginLogin
Might make SBS readonly: thread

SHA-256 Hash Function

Root / Submissions / [.]

SimeonCreated:
Download:QKK8Q5GM
Version:2.2Size:3.4KB
This is a hashing algorithm that can take an input of any length and return a unique 64-character-output in hexadecimal (256 bits). The great thing about this is the feature called the Avalanche Effect, where you can calculate the hash of a huge file of any size (gigabytes, terabytes in size), then change a single bit and recalculate that hash, now both hashes will be entirely different hashes with around half of the bits flipped. Because of this, the SHA-256 algorithm (with salt) is used to store sensitive information in databases across the flat earth. Using the fastest computer in the world, it would take roughly ten times the age of the universe to reverse engineer one of these hashes using the traditional brute force method. So if you're going to have a password system (or something similar), then hash the password and compare it to the hash of what the user types. This will make the password almost guaranteed impossible to crack. That's how programmers work with passwords.

Instructions:

Usage:
DIM H%[8],K%[64] INITSHA256 'One-time initialization

PRINT SHA256("FOO")
PRINT SHA256("BAR")
Prints out: "9520437CE8902EB379A7D8AAA98FC4C94EEB07B6684854868FA6F72BF34B0FD3" "81F5F5515E670645C30C6340FE397157BBD2D42CAA6968FD296A725EC9FAC4ED"
@New_3DS:          382.37 Hashes/Second
@Original_3DS:     100.67 Hashes/Second

Replying to:IAmRalsei
Faster version hype!!!!
Simeon teased an even faster version

Replying to:IAmRalsei
Faster version hype!!!!
Yours doesn't include number bounding, so the numbers overflow to >32 bits and get an error when using HEX$ After adding the bounding, it's much faster than mine still but the outputs are wrong so I probably mistyped something, and will keep debugging. I need to find a better way to bound check, the current solution is as follows:
DEF BOUND(N)
 WHILE N>2147483647 N=N-4294967296 WEND
 WHILE N<-2147483648 N=N+4294967296 WEND
 RETURN N
END
And that's the only solution I've ever got working, the reason N AND &HFFFFFFFF doesn't work is because the bits convert to all 1s when the number exceeds 2147483647. It's kind of buggy in some ways.

Replying to:IAmRalsei
Faster version hype!!!!
If you add 2 integers the result will be an integer but only if you use non-constants:
X% = 1
?&H7FFFFFFF + X% '2147483647 + 1 = -2147483648
A lot of people don't seem to know this (I think I wasn't fully aware of it until pretty recently) probably because of confusion when testing it. ?&H7FFFFFFF + 1 is 2147483648, which makes it seem like SB always converts integers to floats when they would overflow. However, the problem is that it's an expression with only constants in it, and SB tries to optimize those during compilation. But for some reason, rather than just computing it normally, SB converts all the values into floats during, does the operations, and then converts the result to an integer IF it can fit within the integer range. So operations done during compilation might not produce the same results as ones done during runtime. EDIT: I just tested it again and it appears to work. Are there certain things which aren't being hashed correctly?

Replying to:IAmRalsei
Faster version hype!!!!
Thanks, I used a combination of your code with other code to make it really fast, and remove all the unnecessary functions. I didn't know that integer variables behaved like that, so I just made all the variables Ints and removed the bounding, the performance improved a lot. I didn't think it was fair to convert the string to array outside of the timer, so, everything is within the SHA256 function except the initialization that only gets ran once. 382 hashes a second from hashing "Hello World" repeatedly for 30 seconds. In your code, you can only hash inputs that are >= 4 characters, that part of your code was really obfuscated so I did it my own way.

Replying to:IAmRalsei
Faster version hype!!!!
Well it's not a string hashing function, it can hash any list of bits. taking a string as input is very limiting since it forces the input to be a multiple of 8 or 16 bits. EDIT: Somehow I never noticed the problem with the string conversion function... For some reason I used CEIL(L DIV 32) when that should be CEIL(L/32)... I'm surprised it didn't cause more problems

Out of range in 0:44 :
s$="GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG"*9999999999999999999999

Replying to:Intellis
Out of range in 0:44 :
s$="GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG"*9999999999999999999999
that long string is definitely out of my range of time I'll use to read it

Replying to:Intellis
Out of range in 0:44 :
s$="GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG"*9999999999999999999999
SB probably can't handle the string size

While the function got unusable on SB4 when directly porting it, bounding the integer values that broke in SB4 made it work again (albeit incorrectly (?)) with a speed of 1060 hashes/sec

Replying to:Intellis
Out of range in 0:44 :
s$="GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG"*9999999999999999999999
I mean, you tried to use a string that would be 5684341886 TB in size (calculation is kinda wrong but close enough), which no system would handle in the next billion centuries lol A 3DS would never be able to do it anyway. You were asking for too much I am aware this convo ended 2 years ago but was worth mentioning