Elysian Shadows

Bored? Need a little bit of a programming challenge, or something to keep you busy?
Perhaps this isn't a challenge for some - there may or may not be a perfectly simple solution. You'll just have to find out!

Without further delay, here's the challenge:

Synopsis: I have created an algorithm to hash a text input - a password to be specific. It's a weak algorithm - no higher math involved.
Goal: Your goal is to develop a script to decrypt any hashed output. You can use pretty much any language you want - Perl, Python, C - I don't care. As long as it's cross-platform and the compiler is free (no Blitz Basic), you're in the clear.
The Algorithm: b = l * square root(2*a)
The Variables:
b = the final cyphertext
l = z1,z2,z3... (all z's strung together)
.....z (all of them) = (x*y)-(t*10)
..........t = the number of times 10 will have to be subtracted from (x*y) to create a single-digit number, such that z is less than 10.
..........x = the numerical value of the character (a=1, b=2, c=3, etc, and 0=30, 1=31, 2=32, 3=33, etc.) THE TEXT INPUT CAN ONLY BE NUMBERS OR LETTERS!
..........y = the character's place in the inputted string (for string "hamburger", h's y=1, a's y=2, m's y=3, etc.)
a = the length of the inputted string (for example, "hamburger" would be 9).
Example:
Input: hamburger
b = 3520793142.1933355146206174612553225957 * 10^9
l = 829858902
a = 9
3520793142.1933355146206174612553225957 = 829858902 * sqrt(2*9)

Rules For Submission
Send me a private message with a link to your source code, along with the compiled binary (if applicable; users using interpreted languages like Python won't need to include a compiled binary, as there is no such thing). You may post a reply saying that you submitted it, but be sure not to include your code or any hints as to how you did it.

The winner will be the first person to submit one that actually works properly. I will announce the winners on Sunday, April 26. So get to it, and have fun!


Update:
You get extra points if your script/program can encode as well as decode. This'll be easier, of course, but still rather useful.
This is optional - the main challenge is the most important part of your submission.

Given your key and algorithm, and assuming that the current character in question is 'e' in the string "hamburger,"
then x = 5, and y = 8,
and if x * y = 40,
then t = 5 (given the number of times that 10 can go into x * y until it reaches a length of 1 digit, which is a number < 10),
and if t = 5,
then z8 = 40 - (5 * 10), which is -10,

so why do you have 5? Am I missing something (yes or no would be polite, if not, I understand)?

The same for the last character in "hamburger," 'r,'
x = 18, and y = 9
x * y = 162,
therefore t = 16,
which makes z9 = 162 - (16 * 10), which is 2.

This is what I get for l when I try to encrypt "hamburger," (only the last two are incorrect):
8 2 9 8 5 8 9 -10 2

wearymemory wrote:Given your key and algorithm, and assuming that the current character in question is 'e' in the string "hamburger,"
then x = 5, and y = 8,
and if x * y = 40,
then t = 5 (given the number of times that 10 can go into x * y until it reaches a length of 1 digit, which is a number < 10),
and if t = 5,
then z8 = 40 - (5 * 10), which is -10,

so why do you have 5? Am I missing something (yes or no would be polite, if not, I understand)?

The same for the last character in "hamburger," 'r,'
x = 18, and y = 9
x * y = 162,
therefore t = 16,
which makes z9 = 162 - (16 * 10), which is 2.

This is what I get for l when I try to encrypt "hamburger," (only the last two are incorrect):
8 2 9 8 5 8 9 -10 2

For 'r', you're quite right - I made a mistake. That's what I get for doing it in my head and entirely too quickly. However, for 'e' you're a bit off. You see, you would only have to subtract 40 from 40 to get a single-digit number: 0. So, while I did make a mistake, your solution isn't quite right.

Thanks for you input - I'll fix the example!

Are you sure that function is even invertible? If the output of 2 different (or more) inputs it the same, how can you know which one was the correct one after decrypting? That's the point of most cryptographic hash functions anyway.

fantastico wrote:Are you sure that function is even invertible? If the output of 2 different (or more) inputs it the same, how can you know which one was the correct one after decrypting? That's the point of most cryptographic hash functions anyway.

Well, fantastico, you've hit it on the proverbial head! There is no way to be absolutely sure what the original plaintext was! Which is why this is a very poor function for password hashing, as several passwords can be hashed the same way. This isn't a problem for you - it's an aid! Say you were trying to crack someone's password, which was (for some reason or another) hashed this way. It wouldn't matter if you got their original password, just as long as the password you got would be hashed the same way, which would of course give you access.

arcelios wrote:I have created an algorithm to hash a text input - a password to be specific.

So, you've got a few options. You can either create a script to display all the possible plaintexts, or you could make one to just display one.

Yep, so this little challenge has failed. Miserably.

Okay, just on the off chance that this bump renews interest, I'll leave the challenge open for one more week. Oh well.

I'd like to take a look at it when I have some time.

I have my program displaying all of the possible combinations, that is, only if you know the length of the original string. In other words, I gave up when I found that the length of the output of the hash is not always going to have a constant similarity to the length of the string given. I got tired of guessing, especially since this encryption is rather useless.

wearymemory wrote:I have my program displaying all of the possible combinations, that is, only if you know the length of the original string. In other words, I gave up when I found that the length of the output of the hash is not always going to have a constant similarity to the length of the string given. I got tired of guessing, especially since this encryption is rather useless.

Well, by all means, submit what you have done. Since this algorithm encrypts so many plaintexts into the same hash, it would be impossible to narrow it down to a reasonable number of choices without some additional knowledge of the plaintext.