Description747 hashes per second on N3DS! Take that, SHA-256!
InstructionsDEF SHA1 ARR, ML OUT N1, N2, N3, N4, N5
ARR = Array of bytes
ML = Length of ARR
N1-N5 = Final block states
O3DS results: 190 hashes/sec
N3DS results: 747 hashes/secNotesNote that SHA-1 is no longer secure, and should not be used for anything important. Don't hash passwords with this. You'll regret it.

13 Comment(s)SimeonScholarReceived for knowing a great deal about programming topicsAchievementsAmazing PageHiddenAchievementsDrawingI like to draw!HobbiesAwesome! Really fast!MasterR3C0RDAmazing ContributorSomeone thinks I'm an awesome person who has done so much for the community!AchievementsThird YearMy account is over 3 years oldWebsiteosu! Is Awesome!I love osu!Express YourselfI was surprised when I had someone in chat run it and get nearly 750 hashes/sec. I assume it's all thanks to not using functions as much as anything else (that really made a difference in performance), the fact that SHA-1 is relatively basic and fast anyways, and not having the HEX$ logic inside of the function. I think there may be problems with strings above 64 bytes though, but I'm not sure.SimeonScholarReceived for knowing a great deal about programming topicsAchievementsAmazing PageHiddenAchievementsDrawingI like to draw!HobbiesIt's still really fast if you put the string-to-array conversion inside the test, 630 hashes/sec
I'm gonna try updating SHA256MasterR3C0RDAmazing ContributorSomeone thinks I'm an awesome person who has done so much for the community!AchievementsThird YearMy account is over 3 years oldWebsiteosu! Is Awesome!I love osu!Express YourselfHonestly, it'd be really really interesting if a method of (ab)using ARYOP could make this go even faster, but I think I already talked to 12 and he said it wasn't possible. Good luck updating your library though, SHA-256 is a lot better than SHA-1 lol12Me21Power UserSyntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfYeah ARYOP only does floating point operations
Bit shifts are REALLY difficult but they can be done with multiplication/division
Other bitwise operations are impossible, though you can use + instead of OR if none of the bits overlap.
Even addition will cause problems because you'll have to do bounds checkingMasterR3C0RDAmazing ContributorSomeone thinks I'm an awesome person who has done so much for the community!AchievementsThird YearMy account is over 3 years oldWebsiteosu! Is Awesome!I love osu!Express YourselfARYOP has #AOPCLP though, would that not work for boundchecking?
#AOPCLP Clamping (Rounding the value of p1 to the range of p2<=x<=p3)12Me21Power UserSyntax HighlighterReceived for creating the code syntax highlighter on SBSNight PersonI like the quiet night and sleep late.Express YourselfIt has to overflow/underflow properly though. It's definitely possible but you'd need like 4 ARYOPs per additionSimeonScholarReceived for knowing a great deal about programming topicsAchievementsAmazing PageHiddenAchievementsDrawingI like to draw!HobbiesI think it's possible, since bitwise operations have mathematical equivalents, the whole overflow/underflow thing could be done by having multiple arrays of the same values, keep one as is, subtract/add 0xFFFFFFFF for two, subtract/add 0xFFFFFFFF*2 for two others... and so on, then you'll have tons of arrays
Then do some max/min tricks to select the values closest to zero, that would work, right?
The mathematical equivalents of bitwise operations is a bit more difficult... but even then (although unrealistic), theres the possibility of multiplying/dividing by powers of 2 in order to get every bit by itself in different arrays, then those operations can be done with ease.
It's too much work in my opinion, and has the possibility of running out of memoryDFrostExpert ProgrammerProgramming no longer gives me any trouble. Come to me for help, if you like!Programming StrengthI made this function. I don't know what is does lol:
DEF FSHA1(N%)
VAR NUMS%[4]
NUMS%[0] = (N% AND &HFF) XOR N%
NUMS%[1] = (N% AND &HFF00) XOR N%
NUMS%[2] = (N% AND &HFF0000) XOR N%
NUMS%[3] = (N% AND &HFF000000) XOR N%
RETURN “&H”+HEX$(NUMS%[0])+HEX$(NUMS%[1])+HEX$(NUMS%[2])+HEX$(NUMS%[3])
END
DFrostExpert ProgrammerProgramming no longer gives me any trouble. Come to me for help, if you like!Programming StrengthI never used XOR so....MasterR3C0RDAmazing ContributorSomeone thinks I'm an awesome person who has done so much for the community!AchievementsThird YearMy account is over 3 years oldWebsiteosu! Is Awesome!I love osu!Express YourselfIt'll just output the input XOR'd with itself for some parts, and output itself for others. X XOR X = 0 and 0 XOR X = X, so this is not useful at all. SHA-1, on the other hand, leverages a lot of different ideas and mechanics in order to do things like the avalanche effect.
Making a toy cryptographic function, in my opinion, is a great way to practice things like reversible and irreversible transformations. If you're wanting to keep data safe, however, depending on things that aren't made by cryptographers is a terrible idea, and you will 100% regret it.SimeonScholarReceived for knowing a great deal about programming topicsAchievementsAmazing PageHiddenAchievementsDrawingI like to draw!HobbiesYeah, like MasterR3C0RD said, you can instantly figure out the password by "encrypting" 0000 with XOR:
0000
0001 (secret password)
=0001
If you XOR-encrypt a bunch of whitespace or repeating characters then anyone can do a bit of cryptanalysis to figure out the password.
What makes SHA algorithms secure is the fact that 32 bits of the message are fed into the hash every round, slower than it get scrambled, so the scrambling takes over. For SHA-2, any bit of the output is dependent upon every single bit of the input, it's just a huge mess of XORs and ANDs and ORs and NOTs and zero-fill right shifts.SimeonScholarReceived for knowing a great deal about programming topicsAchievementsAmazing PageHiddenAchievementsDrawingI like to draw!HobbiesA strong cipher needs both substitution and transposition, XORing is only substitution so it's susceptible to frequency analysis. Chances are there's whitespace in an "encrypted" file, which would look like repeating symbols, take the repeating symbols in binary and XOR them with a bunch of whitespace in binary, to get the repeating password in binary, then you just need to know where that password starts and ends within those repeating bits.
For XOR you only need two of the three values before you can compute the unknown value with certainty. In this case the cipher is one of the values, and the input we think it is, is the second value.

`#AOPCLP Clamping (Rounding the value of p1 to the range of p2<=x<=p3)`

`DEF FSHA1(N%) VAR NUMS%[4] NUMS%[0] = (N% AND &HFF) XOR N% NUMS%[1] = (N% AND &HFF00) XOR N% NUMS%[2] = (N% AND &HFF0000) XOR N% NUMS%[3] = (N% AND &HFF000000) XOR N% RETURN “&H”+HEX$(NUMS%[0])+HEX$(NUMS%[1])+HEX$(NUMS%[2])+HEX$(NUMS%[3]) END`