This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
Dave-ee Jones's profile picture

Creating an "obscurer" (cryptologic)

Started by Dave-ee Jones, 27 April 2018 - 03:18 AM
Dave-ee Jones #1
Posted 27 April 2018 - 05:22 AM
Hoi!

Been a while, but I'm playing around with creating a hashing algorithm. Basically all it's doing is obscuring the string (like every other hashing algorithm), but in a way that's still predictable in a sense that you could spend a few hours creating a reversing algorithm.

Are there any tips from the nerds themselves regarding the below code? Any immediate issues that need to be looked at? Any quick ways of reverting the code? The code isn't meant to be reversible, it's just meant to be a hashing algorithm so that you can compare strings.

Basically what my code is doing is grabbing a "dex", which is a table of 20 4-digit numbers (the numbers could be 1-digit, 2-digit, 3-digit etc. etc.) but it's kinda like an SSL certificate. If one user hashes a string with a dex, another user needs to use the same dex to get the same hash (or even decrypt the hash).

To be honest, as I'm typing this I'm understanding it way clearer, haha! But still, tips and suggestions would be good!

The only issue I can find with the dex is that anyone can grab a dex from a computer, so the dex itself isn't secure but the hash is secure if the dex is, if you get what I mean.

A link to the Github paste is below. It's only 45 lines, so no biggy. And I made it so the strings are "easily" understandable.

Thanks!



Program usage: hashtest <path-to-dex> <string>


Example of a dex (copy-paste to a text file to test the program if you want):

{
  "6854",
  "2422",
  "5194",
  "9359",
  "3920",
  "6207",
  "9857",
  "1821",
  "0315",
  "0681",
  "3310",
  "2616",
  "5582",
  "3201",
  "7485",
  "8669",
  "9176",
  "1625",
  "0670",
  "5816"
}

If you change a number in one of the indexes in the table you'll notice not that much changes in the hash intervals. Ideally I'd like it to change the hash completely but y'know, that could mean a couple hundred more lines of code.
Edited on 27 April 2018 - 04:46 AM
Dave-ee Jones #2
Posted 27 April 2018 - 06:46 AM
And yes, if this turns out to be any good I'm calling it dexter. :)/>
Marc1miner #3
Posted 08 May 2018 - 05:20 AM
There are a couple of things you can do which make your hashing a lot saver

- make the input in binary, by converting the characters to ascii ex. t = 116, e = 101, s = 115, t = 116 and then to binary 1110100 1100101 1110011 1110100 ("test" in binary)
- flip them all over 0001011 0011010 0001100 0001011
- x-or this with any 8-bit number ex. 58168101 = 1101110 1111001 0011001 00101
this will be the next number: 1100101 1100011 0010101 0011111 = 213437087

example for x-or function (assuming you put the binary in tables)

function xor(int1, int2)

result = {}

for i = 1, #int1 do
if int1[i] == int2[i] then
result[i] = 0
else
result[i] = 1
end
end

end

The good thing about this is that although they might know all dexes it is still very hard to reverse
also an added benefit, how longer the password how harder it is to reverse
note: the longer the "salts" how securer the hash
Edited on 08 May 2018 - 03:54 AM