• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Challenge, for anyone that is willing.

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
K

KraziKid

Member
​
Joined
Nov 22, 2002
I recently decided to work on a computer program for submission int competitions. I decided to work on the topic Encryption. So, over the past few days I came up with my own unique algorithm based upon an inspiration from an AP test. I have the ouput of running a string through the Encryptor. Here it is:

String 1:
Ǻ0½⌐lcb|n⌐lR▬~╪

String 2 (different from String 1, and longer):
/§%¿ òé~½ &┐0½ k═π╠ ÇZ╬½nOh☺[╝nOE&3⌠¬♀ss╬½¬♀╤[|√

I would like people to attempt to crack it, and see if they are able to resolve the original string. If my calculations are correct, then there are 255! (255 factorial) different possiblities that the same string can be encrypted, depending on some factors set by the user. So if you have the time, please attempt to crack this and post your results.
 
Perhaps I am misreading your statement, but when you claim that there are 255! different possibilities that the same string can be enrypted, do you mean that a single string does not yield a single distinct encrypted string? If a distinct string can be encoded in multiple ways, then how will you decrypt it? Perhaps I am just a dummy, and someone here can enlighten me. It does appear the your strings above may be vulnerable to frequency analysis, but I am not sure if there is enough data available to do it.
 
srimmer said:
Perhaps I am misreading your statement, but when you claim that there are 255! different possibilities that the same string can be enrypted, do you mean that a single string does not yield a single distinct encrypted string? If a distinct string can be encoded in multiple ways, then how will you decrypt it? Perhaps I am just a dummy, and someone here can enlighten me. It does appear the your strings above may be vulnerable to frequency analysis, but I am not sure if there is enough data available to do it.
Click to expand...

No, that is not mean that a string is randomly encoded. Based on a few factors set by the user at run time, it will encrypt and decrypt the same string correctly. Now if I change the factors, then it will be different, but will still encrypt and decrypt properly. The reason I chose 255! is because based on those factors, there are that many possible ways to encrypt the same string, using different factors. But if those factors are entered the same in the next run, and you input encrpyted text, then it will decrypt properly. I know I am being a little abstract, and out there, but I don't want to give away how it works yet. I still consider it beta code, and will be improving on it. I just want to see if anybody is able to crack those two strings.

Can you give us the source to your encyryptor program also?
Click to expand...

In due time. As of right now, no. I am planning on submitting to competitions (LISEF, Siemens-foundation, and a few others), and don't want my code wandering the net. After the competitions are over, and as long as there is no commercial future, I will share the code.

EDIT: Just modified my algorithm. Here are string 1 and 2 with the new algorithm (shorter, but in theory just as secure)
1:

Ǻ‼ cb¥TR▬g

2:

/§¿%òé½~&┐½0k═╠πÇZÇZh☺h☺E&R▬ssM²╤[
 
Last edited:
Btw, you are able to decrypt these with one of the programs you've written, right?
 
There are a few things which make this an utterly worthless "challenge":

The output is obviously binary data, and the fact that you've pasted it into "Post" box means that it's almost certainly not in the same format as it originally was. As, we don't even have valid data to even start with, how can we be expected to decrypt it?
(Eg. in string 1, there is a double-exclamation mark, which isn't in the standard ASCII set. Should we treat it as a double-exclamation mark, and thus treat all the other characters as Unicode too, padding with 0x00 to make them into double-byte characters, or, should it be considered as two separate characters: 0x20 and 0x3C (and if so, in what order)) For us to even have a chance, you should post a hexadecimal representation of the data so that it doesn't suffer any corruption.

Secondly, we aren't given any information as to what, at least the 1st string is supposed to decrypt as. I'm sure I could make up an algorithm that made it decrypt to "Hello World" or "Apples". They aren't necessarily right, but without any way to test it, other than posting here, and waiting for you to say whether it's right or wrong, we can't know.
For a true test of the algorithm's strength, we should at least have a copy of a compiled program with which to encrypt and analyze our own data for testing. For you to assume that the algorithm is secure just because only you know it, and because nobody could decrypt a couple of strings that you'd encrypted using, it isn't very wise. (As someone relatively famous once said: "Security through obscurity is no security at all".)

I also don't really see why you're so concerned about releasing your algorithm. Seeing as you've taken the inspiration for it from an AP test, it's unlikely to be truly secure, and so is probably not going to become the next 3DES/AES etc. Yes, you intend to enter it into these various competitions, but if I were in the same situation, I'd be only too willing to allow other people to look at it, to see if it was, in fact, secure. The last thing you probably want is for you to submit it as your entry, and have some math-professor look at the algorithm for 30 secs, and immediately see a flaw in it which you've missed. (That's not to say that just because you post it, and nobody sees any problems that it's definitely secure, but it's always good to get a few more opinions from people who may have much more experience in the area than yourself.)
 
unless hes going to some school and this was his assignment "to decrypt the bit haha" ...
 
XWRed1 said:
Btw, you are able to decrypt these with one of the programs you've written, right?
Click to expand...

Yes, I am fully capable of decrypted it. MetalStorm, the characters above are ASCII, they are not binary data. The double exclamation mark stands for two seperate characters (which are different if I may add). I will supply you with a copy of the executable if you would like, but give me some time to work on the code some more. Every day I am making it more efficient.
 
Ok, so now I know that it is two seperate characters, but unfortunately, we still don't know what order the two characters are supposed to be, since big-endian and little-endian systems would represent them differently.

Make it easy for everyone, and post a hex representation.

I'm hoping you know what that means, but just in case, an example: The hex representation of the string "Hello" would be: 48656C6C6F

While you're at it, upload a copy of the program somewhere and link it.
 
...If it's ASCII data, then it's not exactly hard to figure out what the values are MetalStorm. Big-endian, little-endian, dosen't matter since it's not binary data, and an 'A' will allways be equal to charachter number 65. You can represent 65 however you want in the program (...I'd just use 'A' and perform transforms on the letter itself), and the results should be the same.


Just how is this encrypted? It's nearly impossible to decrypt something if we don't know a general idea of how it's done (a simple substitution, add X to the ASCII value of the charachter, some kind of special matrix transform, what?). No need for excruciating specifics, but we should at least have a general idea of how it works.

JigPu
 
do the orginal line 1 and the new line 1 still = the same thing

couldnt you use that for something
 
Crash893 said:
do the orginal line 1 and the new line 1 still = the same thing

couldnt you use that for something
Click to expand...

Yes. the original Line 1 and new Line 1 equal the same string.

JigPu, I think you could call it a matrix transform, but I do some things beforehand (as in hash, and a few other things, I'm not exactly sure how to classify).
 
JigPu said:
...If it's ASCII data, then it's not exactly hard to figure out what the values are MetalStorm. Big-endian, little-endian, dosen't matter since it's not binary data, and an 'A' will allways be equal to charachter number 65. You can represent 65 however you want in the program (...I'd just use 'A' and perform transforms on the letter itself), and the results should be the same.
Click to expand...

It is not all ASCII data, there are two NON-ASCII CHARACTERS in string 1 alone.

‼ (Double-exclamation mark)
and
▬ (A "black rectangle")

Now, because these are double-byte characters, they are stored differently on big and little-endian machines.

So, little-endian would be (assuming that non-unicode characters are to be interpreted as single-byte):

C7BA3C20206362A55452AC2567

Big-endian:

C7BA203C206362A5545225AC67

If there's no clear information on how to interpret the data, how the hell are we supposed to even begin decrypting it?? (Or is the fact that their is no information on this subject part of the security?!?)
 
...The double exclamation mark is charachter number 19. The 'black rectangle' however is much harder to find. Based on my searches, I would guess that it is either charachter 0, charachter 32, or charachter 255. Since I think 32 is actually the space charachter, then it's either 0 or 255.

We need to know which it is before we proceed....
JigPu
 
when translated how many charters are in line 1 and 2
 
1a; Ǻ0½⌐lcb|n⌐lR▬~╪

2a: /§%¿ òé~½ &┐0½ k═π╠ ÇZ╬½nOh☺[╝nOE&3⌠¬♀ss╬½¬♀╤[|√



1b: Ǻ‼ cb¥TR▬g

2b: /§¿%òé½~&┐½0k═╠πÇZÇZh☺h☺E&R▬ssM²╤[


here are the two strings ( i think its unfair personly to change the encoder in the middle of the challenge)
 
You must log in or register to reply here.

Similar threads

C
squidguard hates me
Replies
1
Views
6K
CougarSE
C
Back