Algorithm encryption

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 [email protected] or [email protected]

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 :).

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.

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...:)

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

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..

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.

Cheers

Cheeseball> Isn't that considered a one-time pad ;)

Quote:

---

for(unsigned int i = 0; i < FInterval; i++)
x = 4 * x * (1 - x / ncMaxX0);
FX = (unsigned int)x;
return FX;

---

This isn't quite what you said....
FInterval = h = 1 to 100
ncMaxXO = 0xFFFFFFFF
X = x = FX

so.... for h number of iterations do Xh = 4 * X(h-1) * (1-X(h-1) / 0xFFFFFFFF)
or new x = 4 * x * (1-x / 0xFFFFFFFF)

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.

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?!

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.

Thank you

Quote:

---

Originally posted here by Casablanca
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.

Cheers

---

well first try making it not shareware because shareware is just another rls for me ;P
Make a demo which doesnt actualy have all the features in it which makes it pretty much impossible (or ****ing annoying) to crack.

Or, you could pack the hell out of it using some lame packer like asprotect (which claims to be unpackable, but definently is). That's what most shareware authors do.....relying on a packer/protector is normally like asking someone to crack your program for a challenge.

Well, it sounds to me like the demo is better than the shareware...

One question... what does "rls" mean? (Real Lamer shite?... maybe?)

if you only use the key one time, yes it would be a one time pad. But using it over and over is also an option, and nearly as secure. As long as the key never falls into the hands of someone else, yeah...it will be secure, simply because there is no "cheater" way to undo an XOR unless the pattern repeats. Also one other note to remember, if you transmit more than one message using this meathod, it gets slightly less secure with each message. "Technically" you can break it using two ciphertexts and a LOT of spare time, simply because you can XOR the word over and over on the key at different offsets and get "pieces" of the plaintext, which can then be used to obtain parts of the key, and try them against the other ciphertext. But anyway...enough about that....:)

Hi again... Ihave been revising my code and realized I could modify it to make it clear and waste less memory. Now the main key is always of type double, although the user inputs it as an int. These reduces the extra variable I defined as x. The method Iterate() is now clearer to see because it needs no scaling as I had before.

Thank u all for your comments.

This has been one of the best threads I've read in a long time. Very informative!

Right... this is the final version of the class TRHCryptor using the algorithm described. It fixes one little problem that occurs in the previous versions. Now, x is not allowed to be negative.

Thanx again to everyone.

I think I remember the math problem you are using from somewhere, is it called a raki series?

It's good to know... I never heard of it

thanx