An encryption algorithm

Re: An encryption algorithm

thornmaker — Wed, 28 Nov 2007 01:24:31 -0600

123 = 278F98
1235 = 278F98E3
321 = E18D5C

Note the 2 in the 2nd position does not get encrypted the same on the third line. So a table like you are suggesting does not work in this case. It appears that the preceding characters affect how each character is hashed but not any of the subsequent characters.

[Edit:] I do find it curious that 2 maps to 8F on the first two lines (when preceded by a 1) and 2 maps to 8D on the third line (when preceded by a 3). Perhaps 22 hashes to __8E ? Unfortunately, not having access to the algorithm (even as a black box) means it's next to impossible to test such things...

Re: An encryption algorithm

buherator — Tue, 27 Nov 2007 09:29:29 -0600

123 = 278F98
1235 = 278F98E3
1234567890 = 278F98DBD882B5F084A8
qwerty = 5F065405015A

You simply can create a table like this to decode anything you want:
\|pos.1|pos2|...
1|27 |? |...
2|? |8F |...
.
.
.

Re: An encryption algorithm

id — Sun, 07 Oct 2007 20:19:25 -0500

btw, I take that back, I had a new line on that.

SHA1 ("TestPassword") = 6250625b226df62870ae23af8d3fac0760d71588

Re: An encryption algorithm

Mordred — Sun, 07 Oct 2007 16:30:22 -0500

ZX Wrote:
-------------------------------------------------------
> 123 = 278F98
> 1235 = 278F98E3
> 1234567890 = 278F98DBD882B5F084A8

From this I can guess it should be trivial to break any such encrypted string with a known plaintext attack, if you have a reliable way of doing it. Sometimes knowing the actual algorythm is not needed ;)

Re: An encryption algorithm

id — Sat, 29 Sep 2007 18:24:41 -0500

sha1 of TestPassword is db97dde4c15810646b3ac15fcc1b8a25dc4c7fcb

any *NIX box should have md5 and at least sha1 installed, easy to test.

Re: An encryption algorithm

Spyware — Sat, 29 Sep 2007 17:53:31 -0500

Sha-1 is 40 chars long: http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1_hashes

Re: An encryption algorithm

Ghozt — Sat, 29 Sep 2007 17:42:11 -0500

Just so I don't have to start a new thread, does anyone know of an algorithm that's 40 characters long? I ran it through hashmaster and it didn't come up with anything.

TestPassword - 52BF31F50EABC35D14D1D91D3DC7D0B8BB955971

- Ghozt

Re: An encryption algorithm

rsnake — Sat, 29 Sep 2007 14:49:45 -0500

Btw, I expanded and released my program in case anyone else has this problem. Granted, it was unable to solve your problem, but maybe in future revisions it may be able to: http://ha.ckers.org/blog/20070929/detecting-hashing-algorithms/

Re: An encryption algorithm

DanielG — Sat, 29 Sep 2007 14:11:29 -0500

I too have had troubles with finding the hash algorithm used for a password stored in a cookie.
I've been trying to see if they used part of a hash because I couldn't find alot of hash algorithms which produce this particular output length (8byte).

I was wondering if hashmasher also checks if the provided is only a part of a known hash algorithm.

These are examples of the hash:

aaaa = DE78DA47D9BAAAC6
aaab = 40676C887DEFCEBA
baaa = E3D3B1E3E6BF6464
test = EDD2A1D1B747B0BD
aaaaa = 039C3D6F2B6C8F81
soho123 = 7B90FCED97DF5011

Maybe instead of just showing "Nope!" you could display the calculated hash for the string.

Re: An encryption algorithm

Anonymous User — Thu, 27 Sep 2007 12:05:36 -0500

You can rule all those out RSnake,
since all hashing algorithm have fixed length.
The first post shows presumely a custom XORing cypher, c.q. transposition because the length varies on entered data.

To be conculsive he just has to generate multiple strings and try to see the XOR pattern, then it could use a salt/key and then you'll you know where the salt or key returns only if you generate multiple strings and compare where XORing returns. You could solve it in the end since it is highly likely that XORing / transposition is used.

Like:

H . . . O . . . C . . . S
. E . L . S . A . K . R . 
. . L . . . L . . . E . .

The only way to know it isn't an encryption algorithm or block cypher like AES, is to watch if every input generates a different result, then you are probably screwed. If it stays the same you will have more luck. What also can be used is to try exotic chars, beyond the [0-9][a-z] since most XORing cyphers don't use them, or are padding them.

My best bet until now is that it looks like a RC4 cipher since it generates a different cyphertext length each time:
http://en.wikipedia.org/wiki/RC4

Anyway, goodluck.

Re: An encryption algorithm

rsnake — Thu, 27 Sep 2007 10:44:20 -0500

id had a good idea, and I ended up building a quick test to see if I could find out for you but alas, it was none of the usual suspects (I haven't built salting into my program):

$ perl hashmasher.pl
Missing vars!
Needs to be in the format hashmaster.pl

Goodbye.
$ perl hashmasher.pl 55555555555555555 4F35F7F3C94A1AF7CE4A2C94691FDEE8F224
Welcome to the hashmaster! Written by RSnake (http://ha.ckers.org/)
Trying MD2... Nope!
Trying MD4... Nope!
Trying MD5... Nope!
Trying SHA1... Nope!
Trying SHA224... Nope!
Trying SHA256... Nope!
Trying SHA384... Nope!
Trying SHA512... Nope!
Trying CRC... Nope!

Done (none found, sorry).

My test included the following: md2 md2_hex md2_base64 md4 md4_hex md4_base64 md5 md5_hex md5_base64 sha1 sha1_hex sha1_base64 sha224 sha224_hex sha224_base64 hmac_sha256_hex sha256_hex sha256_base64 sha384 sha384_hex sha384_base64 sha512 sha 512_hex sha512_base64 crc32 crc16 crcccitt crc crc8

So either it's using a salt (you can probably verify that by typing the same password over and over again and see if it comes out at something different) or it's using something other than one of the usual suspects.

Re: An encryption algorithm

ZX — Wed, 26 Sep 2007 15:15:48 -0500

That is the reason I thought it could be reversed without the actual encrypting function, but I've ran out of ideas.

Re: An encryption algorithm

auron — Thu, 13 Sep 2007 06:49:44 -0500

Right now, the only thing I can see from the codes is that probably there's a linear dipendence from the previous char. This means:

c_n = f(m_n,n)+m_(n-1) mod(256)

c_n = n char of the crypted string
m_n = n char of the message string

that's because 8f-8d = 2 = 3-1 , and we can see that the coding function has not dipendences from the next char cause in 123 and 1235 the first 3 chars are the same.
for a deeper investigation, i think it would be required much time...

Re: An encryption algorithm

ZX — Wed, 05 Sep 2007 04:01:56 -0500

55555555555555555 = 4F35F7F3C94A1AF7CE4A2C94691FDEE8F224
0123 = 6B9A4899
321 = E18D5C

Re: An encryption algorithm

Gareth Heyes — Tue, 04 Sep 2007 20:40:43 -0500

I suggest using the photoshop colour picker. That should "decrypt" it lol.

Re: An encryption algorithm

thornmaker — Tue, 04 Sep 2007 16:25:41 -0500

55555555555555555 = ?
0123 = ?
321 = ?

Re: An encryption algorithm

Anonymous User — Tue, 04 Sep 2007 11:01:51 -0500

Looks like some sort of custom Railfence Cipher =>http://www.math.temple.edu/~renault/cryptology/railfence.html

Most custom ciphers are based on very simple ones that involve xoring bytes.

An encryption algorithm

ZX — Tue, 04 Sep 2007 10:09:11 -0500

Hello there,
Im not sure this is the right section, but feel free to move the topic.

The thing is, I came across an algorithm and it appears to be a custom. Since I have nothing better to do I've decided to try figure it out, but with no success.

Here are the strings and the result after the encryption:
123 = 278F98
1235 = 278F98E3
1234567890 = 278F98DBD882B5F084A8
qwerty = 5F065405015A
* result is in hex

Looking at the first three it seemed, well, easy, but.... you know...
Hope someone could help me.

Cheers and thank in advance.