Hello all!
this is the first message I write on this forum. The reason for me writting here is that I have coded an Encrypting/Decrypting Win32 based program using an algorithm that, as far as I know, no onehas used yet. I would like to know if it is a good algorithm or not, and that is why I attach an encrypted file created with this applicationin case anyone is interested in cracking it. I think this is the best method to check wether the algorithm is worthless.
I also include the application I use to encrypt/decrypt files. It is not finished at all, but it works as far as encryption/decryption goes, and is enough for testing it. If it happende to be usefull I would finish it up by including better interface to it.
It has been programmed using Borland C++ Builder 4.0, which I obtained from a PC Magazine.
Oh, one last thing. Because I am convinced that the secret of the encryption is not on the algortihm but on the two keys it uses, I include the equation I use in the algorithm. This is x = h * (1 - x) where h is a constant between 0 and 4, and x a number between 0 and 1. This equation presents chaotic behaviour for values of h close to 4. I have scaled the function so that x is an integer (four bytes).
I have read in some books, and text files, that an encryption based on XORing is an easy one to crack. Well, my algorithm is based in XORing so I guess it should be pretty easy... although I would like to make sure of this.

If anyone is interested in cracking the file please do... and thank you for your interest. Oh, the decrypted filename is an ASCII text file in english, whose name can be read by HexEditing the file. Well, thanx a lot. Interested people can e-mail me at r.hermoso@qmw.ac.uk or r.hermoso@telefonica.net

March 14th, 2002, 04:13 AM

smirc

Nifty little ap. I'll have a closer look at it over the weekend but it looks pretty cool. I can't really comment on the algorithm because you haven't included the source code :).

March 14th, 2002, 05:52 AM

souleman

x = h * (1-x) ??? I assume the two x's are not both supposed to be x? so it should be:
e = h * (1-x) ? Just checking. Also, you said x is an interger....which x? the first, or the second? If it is the second, that means that x is either 0 or 1? so you total possible values are [0..4] * (1-[01]) ? That would meat that it was always between 0 and 4. If thats the case, this really sucks. So, I assume you mean the other x, which I labeled e.

Is this supposed to be symetric or asymetric encryption (public key or shared/private key)? What does the algorithm give you? Is it the actual encryption key, which is then xor'd with the plain text? Just curious. Like smirc said, give the source code out. It makes it easier to play with. If you keep the source secret, then you get a false sence of security. If you make it public, then you can find out the truth. I am not sure if anyone on here is a crypto/math expert, but a lot of us are amatures that like playing around with encryption.

March 14th, 2002, 08:07 AM

Cheeseball

Actually XOR encryption is "technically" secure, as long as the key and message are of the same length....Just thought I would comment on this...:)

March 14th, 2002, 11:37 AM

Casablanca

Source Code + explanation of algorithm

Right... sorry for my last message, it is clear that I have not explained the algorithm properly at all. I include the C++ class that is the heart of the encryption (lets call it the encrypting engine... I like how it sounds ;)). Right. To the point. The algorithm uses private keys... actually 2 keys. Now, the equation I give is correct... I meant the two x. This is beacuse it iterates the formula.

So, x = h*(1-x) means that the new value for x uses h and the actual value of x...
The first key in the algorithm is x (call it x0 because it is the initial value for it). The second key tells the library how many times to iterate the function before returning x.
I could insert a third key that would change h, giving a new degree of freedom. But this is not implemented... so far.

Now, as I explained in the previous post, the function above presents chaotic behaviour for values of h close to 4... but never greater to 4. This is the main feature I wanted to exploit. However, the initial x (that is x0), must range between 0 and 1 otherwise the iterating function blows up after a few loops.

Lets say we want to encrypt the string "Encrypt this". It has a length of 12 bytes. what I do is get the first four bytes ("Encr"). Use the initial value for x (that is x0 which is the first key), iterate the function a number of times given by the second key and obtain a new value for x. Because that value of x is an integer (four bytes long), I use it to XOR the first four bytes from the string... and the result is the encrypted string. I then read the next four bytes ("ypt "), iterate the function again, but this time use the value previously obtained (not x0 again, but the x we obtained in the previous encryption) and carry on like this until we run out of bytes to encrypt.

To decrypt, we simply use the same keys and repeat the process... the end result is the original string. And that is all the secret to it.

Comments on the source code. The source code is not commented, so it might be messy to follow, but I hope that with my explanation it gets easier. Probably the code can be improved for speed, or clarity, but this is what I can do. If any of you has any comments on it, please let me know. The class includes methods to recall the original value of x (x0, which is one of the keys). I do not include the source code for the program itself, which is actually unimportant for the encryption. I created another class for encrypting files and putting them together into a single file... but again that has naothing to do with the encrypting technique or code itself.

Thank you for your comments

March 14th, 2002, 12:26 PM

bpx

why make it shareware? it's more of a demo btw. I still managed to remove the nag and shareware text. if you will make the final version a demo/shareware then you have to give it more protection....maybe a packer/protector to secure it a little more..

March 14th, 2002, 05:38 PM

Casablanca

why shareware

There actually no reason for making it shareware other than for advertising me ;). Ypu r absolutely right about having more protection if I wanted to make it demo/shareware properly... but I am not poficient enough in programming for that. I would have to learn some techniques first. Now, if someone wants to teach me, please do.

This is a lot better then how you explaied it earlier. Not sure why you picked the number 4 though. I don't have time to test it right now, but I will try and get back with you on this. The one problem that I can see off the top of my head is that you are always using int's. That means you are wasting a lot of math, and decimal places that could possibly be used.

March 15th, 2002, 03:28 AM

Casablanca

hmm... my big fault

I am kind of sorry for messing things up so badly. So it happens that the equation is not quite what I stated earlier, but rather....

x = h*x*(1-x)

or

x = h*(x - x^2)

and h = 4 is the value I chose... for no particular reason. It looks more elegant that 3.999.
Please, slap me... I deserve it.

And... what is padding? It might be after all that the algorithm I describe has already been used before?!

March 15th, 2002, 03:59 AM

Casablanca

On other thing. I do not quite understand what you mean when you say...

FInterval = h = 1 to 100
ncMaxXO = 0xFFFFFFFF
X = x = FX

Because h != FInterval. FInterval is the number of times the function is iterated before the method returns a value. and h = 4 in the code. This is so because in order to obtain chaotic behaviour from the iterative process, h must be close to or equal to 4.

ncMaxX0 is used only as a scaling factor on the function... (more on this if anyone is really interested)

On the function I do not use ints. x is defined as double, and therefore I do not think it wastes any maths (I might be wrong, of course... if so, please correct me again)

The reason for turnning x into an int might be stupid (let me know if so), but here is my reasoning. Throughout my experience in programming, when dealing with double precision numbers which are either too high or too low, and repeated in a iterative calculation, the final result might vary "slightly" when calculated on different machines/processors... (why? I do not know... I guess it has to do with rounding errors). Since I wanted the program to work the same on all machines, I decided to remove the problem by making the return values integers. Now, is this logical/true, or is it simply stupid? Because if it was so, I could simplify the code quite a lot.