talkmagic.co.uk

Hehe. Bad magic number is very apt

A_n_t wrote:It looks like hex to me. Is it the hex code for talkmagic? I do not have a hex calculator on my netpad.

It is not, but you can find one here: http://www.dolcevie.com/js/converter.html

I don't have time to work on this, but some ideas for others:

the string is in Hex, so there's a good chance that there's an encryption being used.

I can't remember the format for an MD5 hash, but the key to the cypher is probably TalkMagic

It's not an IP address or MAC code, and the wrong length for a WEP or WPA key.

Hope that helps/sends you off on the wrong tangent.

Its the right length for an SHA1 code but I cant find a decrypt where you give it the keyword.


heck, I even sound like I know what I'm talking about. I dont.

Are you hoping this will go on untill the start of April (lets say...the first) where you will reveal the answer?

The answer will be given on the first of December, either by the winner or myself.
No April fool or other prank. It's actually quite basic encryption. And that's a clue...

Discombobulator wrote:Its the right length for an SHA1 code but I cant find a decrypt where you give it the keyword.


heck, I even sound like I know what I'm talking about. I dont.

It's not an hashing algorithm (otherwise it would be very difficult to reverse anyway): Ted has given us two different encrypted strings and they have different length.

Today I finally found an interesting regularity, though I can't figure out the solution yet. For everybody, I've tried many standard symmetric encryption algorithm with "TalkMagic" as ket, but none has worked for me: DES, AES, TDES, BlowFish, RC5... I'm really thinking about this problem a bit too much.

It's not a PGP encryption with talkmagic as the keycode perchance?

A_n_t wrote:It's not a PGP encryption with talkmagic as the keycode perchance?

That would require another key: PGP uses asymmetric keys algorithm, which in turn need two keys to decode, a public and a private one.

Not always. It supports symmetric also.

Ted wrote:Not always. It supports symmetric also.

You are right, I didn't know.

I'm pretty certain it's SHA-1 salted with the string "TalkMagic".
Two reasons for this - one, it's 40 characters exactly (which would be correct for SHA-1), and it's only using Hexadecimal values (as others have pointed out).
The problem with this theory is that any hash is by definition not reversible (hashing algorithms are 'trapdoor' functions, they only go one way). So, you would need to blind guess the input e.g. the string 'mind.hak.me' salted with the string TalkMagic would give you a89af7c21d24840367d18367562ad638ded46970 as the output...look familiar?
So, the problem now becomes one of getting inside of Ted's mind to figure out what he might have put into it.
A second problem is that, elsewhere, Ted has posted a shorter string, which does not meet the criteria for the above theory.
However, neither of these strings respond to decryption in simple symetric ciphers (Blowfish, DES etc), so it is possible this is a red-herring. Using very simple ciphers such as vigenere or substitutions reveals no usable results.
I put this out there for whatever it's worth, and go back to doing my normal work
Len

Ted wrote:

MiKo wrote:I guess asking for another encoded string would be too much...

92dc00ca32e0

That's why I asked for another encoded string. It's not SHA1.

Actually (and sorry for the double posting), at the moment I'm thinking about some kind of bit to bit operation. The reason for this is that if you consider the two encoded strings in binary, they are very similar in the first bits of each character...

MiKo wrote:

Ted wrote:

MiKo wrote:I guess asking for another encoded string would be too much...

92dc00ca32e0

That's why I asked for another encoded string. It's not SHA1.

Yes, as stated, that's one of the problems with my theory...but is it possible they are differently encoded - you asked for another encoded string...doesn't mean Ted encoded it the same way.
It _looked_ most like blowfish at first, but it certainly isn't (even if you output Base64)

Len