I 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.
Replying to:
DFrostI 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
Yeah, 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.
It's still really fast if you put the string-to-array conversion inside the test, 630 hashes/sec
I'm gonna try updating SHA256
Replying to:DFrostI 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
A 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.
Honestly, 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 lol
Yeah 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 checking
It has to overflow/underflow properly though. It's definitely possible but you'd need like 4 ARYOPs per addition
I 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 memory
