Dynamic generating encryption algorithms

Jef · Post by **Jef** » Wed Jan 30, 2008 6:48 pm

The idea is to create a symmetric algorithm with variable size and random usage of specific commands.
So, if you are using it to protect your executable, every encryption will have a unique algorithm. So it's not necessary to use a key.

Unique algorithms (with variable size) will prevent a generic crack, in case you are a developer of software protection systems.

My theory about data encryption is to make a tool that will encrypt a data file and will put the decryption (binary) code in to the data.
So, the decryption tool just knows where to find the decryption code in the data file, and then use it.

You will find attached (and at my web-site) a simple demo code that generates ether source code in C (with inline assembly) or binary code.
The source code is written in C and it's ready to be a DLL

01000101 · Post by **01000101** » Wed Jan 30, 2008 7:48 pm

why dynamically encrypt? why not just have a relatively large matrix of different encryption schemes and implement them on a file based on certain file attributes or other static variables. or encrypt the software based on hardware attributes that way it has a unique decryption algorithm per computer.

Jef · Post by **Jef** » Wed Jan 30, 2008 8:04 pm

01000101 wrote:why dynamically encrypt? why not just have a relatively large matrix of different encryption schemes and implement them on a file based on certain file attributes or other static variables.

If you see the source code and the result (generated code) you will see that i used as well variables (that are also random).
If you encrypt with this method 1.000.000 times the same file, you will get 1.000.000 different encrypted files.
In case that you include the decryption code into the data, you will also get 1.000.000 files with different size.

01000101 wrote:or encrypt the software based on hardware attributes that way it has a unique decryption algorithm per computer.

Because this cannot be decrypted in other computers

elfenix · Post by **elfenix** » Wed Jan 30, 2008 8:49 pm

Because this cannot be decrypted in other computers

I don't get that this is a bad thing?

The security of any encryption algorithm is the security of your key.

How about this.... I provide a file, without the key, and give full instructions on how I made it. I'd bet a cool amount of cash you couldn't tell me the contents in a month, and a substantial amount you couldn't tell me in a year.

Jef · Post by **Jef** » Wed Jan 30, 2008 8:59 pm

Fate wrote:
Because this cannot be decrypted in other computers
I don't get that this is a bad thing?

unless you want to use your encrypted data in your second pc (home/office), or motherboard damage.

Fate wrote: The security of any encryption algorithm is the security of your key.

How about this.... I provide a file, without the key, and give full instructions on how I made it. I'd bet a cool amount of cash you couldn't tell me the contents in a month, and a substantial amount you couldn't tell me in a year.

If you mean that the algorithm is common/public/known with this "give full instructions on how I made it",

yes this is the best. But these algorithms are not symmetric.

01000101 · Post by **01000101** » Thu Jan 31, 2008 2:32 am

asymmetry is what you want right?. if you want dynamic, well that's the way to do it, using asymmetric values. you can go as crazy as encrypting data with random memory data or use hardware ID values to encrypt (not as much asymmetry, but you get the point).

If you are really THAT concerned about encryption to take it to that level, then data lost is better than data easily recovered. If your data is so locked down that the only way it can be corrupted is by hardware failure, then that I'd say that's pretty good. On the other hand, if you want portability in the cipher, then you cannot rely on hardware or anything else truely unique per computer. But we already have good encryption standards build just for portability and strength (T-DES, AES, MD5, SHA, etc...)

Solar · Post by **Solar** » Thu Jan 31, 2008 2:39 am

I strongly suggest the book "Applied Cryptography" to give you a good start on the subject. Some general truths on cryptography:

Hiding key or algorithm in the cyphertext does not work. One look at the decoding tool, and the attacker has broken your cypher.

Generating cypher algorithms "randomly" (not sure how this should work at all, and not in a mind to dig through your code) will most likely result in "weak" ciphers, which do not properly protect against statistic attacks.

Passing the algorithm to the receiver over a "secure channel" doesn't solve any problems, as that is essentially the same as using a common symmetric cypher and passing the key over a "secure channel".

I'd say, leave the invention of new crypto technology to the pro's, there is a reason why cryptology has become a science of its own. Any hobbyist approach on the subject is bound to result in tools that give you a false sense of security, at best.

Alboin · Post by **Alboin** » Thu Jan 31, 2008 3:09 pm

PostPosted: Thu Jan 31, 2008 2:39 am Post subject:
I strongly suggest the book "Applied Cryptography" to give you a good start on the subject.

The Handbook of Applied Cryptography is a free online book on the subject, if I do so recommend. I haven't read it myself, but according to Schneier, "This is a good book, and well worth downloading."

bewing · Post by **bewing** » Thu Jan 31, 2008 3:24 pm

On the other hand, data compression is also a form of encryption -- and one where a hobbyist can fairly easily come up with a major new advance in the field.

Jef · Post by **Jef** » Thu Jan 31, 2008 5:11 pm

You are right when we are talking about data.
The code a have attached was created to be used by a tool that protects executables. If the code that protects the exe has variable size and different encryption algorithm every time its protects an exe, then the hacker cannot produce a generic crack.
So actually you don't need a password or key to decrypt it.
It always decrypted at the startup of protected application.
This project done before 7-8 years.
But as an idea to the specific target, is still good protection.

xxxcastenada · Post by **xxxcastenada** » Thu Jan 31, 2008 6:18 pm

IIRC

1. It's very difficult to generate true random numbers with computer based systems. Computers simulate determinism, meaning for a specific input the output will always remain the same. 1 + 1 always = 2. Knowing the output the input can often be deduced. The best most people can do to simulate random numbers is to base their encryption off of a file containing weather data, a file containing random radio static or something similar.

2. Your solution in using encryption to defeat cracks sounds vaguely like a polymorphic virus.

http://en.wikipedia.org/wiki/Computer_v ... rphic_code

Solar · Post by **Solar** » Fri Feb 01, 2008 1:44 am

@ bewing:

Compression is not a kind of encryption. If you believe that, that's the first step towards an encryption scheme that a cryptoanalyst will wet his pants over by laughing so hard.

Same goes for hobbyist ciphers, at least unless the hobbyist has studied the subject thoroughly. I seriously doubt that anyone who has not at least a university degree in maths (or equivalent education) to come up with an encryption scheme that would withstand a dedicated cryptanalist for more than a couple of days.

@ Jef:

If the "security" lies within "hiding" the decryption code in the cyphertext, it's not "secure" at all. I asked this before, I ask it again: If the intended recipient is able to find the decryption code within the cyphertext, how do you keep Malory (the malicious attacker) from finding it, too? All he had to do would be to disassemble the cyphertext at various offsets and check if what comes out is meaningful?!?

Candy · Post by **Candy** » Fri Feb 01, 2008 8:04 am

bewing wrote:On the other hand, data compression is also a form of encryption -- and one where a hobbyist can fairly easily come up with a major new advance in the field.

How do you determine that a compression algorithm works? If the file is smaller, it works.

How do you determine that an encryption algorithm works?

Jef · Post by **Jef** » Fri Feb 01, 2008 3:09 pm

xxxcastenada wrote:2. Your solution in using encryption to defeat cracks sounds vaguely like a polymorphic virus.

yes, i know.
a lot of times Norton anti-virus ether report the protected executable as "maybe infected" or make a lot of delay before let windows run the protected exe.

@ Jef:

If the "security" lies within "hiding" the decryption code in the cyphertext, it's not "secure" at all. I asked this before, I ask it again: If the intended recipient is able to find the decryption code within the cyphertext, how do you keep Malory (the malicious attacker) from finding it, too? All he had to do would be to disassemble the cyphertext at various offsets and check if what comes out is meaningful?!?

and how you know where exactly is the decryption code?
If its multiplexed with the data and its only the half of the code ?
I mean that decrypter has the half code and data has the other half code.

Believe me, if i give you a protected executable from this tool, you will try too hard to crack it.
I don't say thats uncrackable. Everything can be cracked. Its matter of time.

anyway, i don't try to prove anything.
If you believe thats its good idea, ok, use it.
If not, don't use it.

Opinions it like ********. All have one