# What do you think of my encryption algorithm

## Recommended Posts

I just wanted to know what you think about this little encryption algorithm i though off by myself last year after discovering that my old one wasen't very secure (encrypting an image in raw form would still leave a recognisable trace of the original image). Basically, it's really simple but effective, and only take about 100 lines of code.

First, i start by creating a 32 bit hash value from a crc32 algorithm using all the chars in the password key. This value is then used to initialise the random number generator (which is the mesmene twister algorithm found on wikipedia). Then, for every byte to encrypt, i xor it with the next random value returned (i know i should use the full 32 bit value instead but for now it make the algo simpler).

I also have an optional bool to encrypt it more times using every letters of the key as a hash to initialise severals more RNGs, then repeat the process above for every letters, but it take more time.

The result is very good, even with one pass. Encrypting an image using this technique generate pure noisy image (every byte from 0 to 255 have about the same distribution with almost no variation; ie. 0.39% or 1 / 256) and is pretty much uncompressable.

Did i just find by accident the best encryption algoritm you can write? And by "find" i dont mean discover because im pretty sure this already been done before...

Edited by Vortez

##### Share on other sites

The strength of an encryption algorithm is not how noisy the image is, but how hard it is to reverse the process without knowing the key.

If you have a 32-bit seed, you only have 232 different possible random number sequences to evaluate. If you know or assume, for example, that the image is a sprite sheet with black background, you can just decrypt the first few pixels and see if they are all black. If they are, you can assume you have found a key that can decrypt the whole image and proceed to decrypt the entire image.

Sounds like an extremely weak cryptographic algorithm if you can make just a tiny assumption about the data it contains.

##### Share on other sites

Actually, now when I think about it, your algorithm is much worse than that. Since you only encrypt a byte at a time, and the sequence of random numbers is fully known, you effectively only have a 8-bit XOR cipher. Not only is brute force viable, but even manual brute force BY HAND is viable since you effectively only have an 8-bit key and thus 256 combinations to manually examine.

##### Share on other sites

Yes, that's why i said you can then add more loops by using a hash for every letter in the password, and even more loops if needed.

You would also have to know the algoritmh used by the RGN.

Ex.

The password "password" would give 1 hash value, then every letter of the pw (8 in this case) would give 8 more hash value. For each hash we xor the data using the above algoritmh by initializing the rgn with the said hash value. Then the entire process could be repeated as many time as wanted.

I beleive in this case it would be pretty darn hard to decrypt.

And yes the 8 bit issue is something i plan to resolve when i have the time.

Edited by Vortez

##### Share on other sites

Your algorithm to generate the random numbers is trivially known. Not only did you say which one you use in your first post, but one can just examine your code and figure it out.

Making several passes with an XOR algorithm is useless. If you make an XOR pass with key A, and then second XOR pass with key B, and a third XOR pass with key C, and so on for how many times you want, then that would be the same as a single pass with the key (A XOR B XOR C XOR... ). No matter how many XOR passes you do, you can decrypt, and consequently crack it, it with a single XOR pass.

If you use different passwords for the different passes, then that would be equivalent to having a single pass with a longer password (or rather, each additional password adds another 32-bits to the seed; not that the combined passwords would generate a stronger single 32-bit initial seed). But, that also multiple passwords.

Edited by Brother Bob

##### Share on other sites

Making several passes with an XOR algorithm is useless. If you make an XOR pass with key A, and then second XOR pass with key B, and a third XOR pass with key C, and so on for how many times you want, then that would be the same as a single pass with the key (A XOR B XOR C XOR... ). No matter how many XOR passes you do, you can decrypt, and consequently crack it, it with a single XOR pass.

But shouln't the difficulty increase with each pass??? i mean 2^32 * 2^32 * 2^32 shound't be better than simply 2^32?

##### Share on other sites

If you have different keys based on different passwords, then yes, that is what I mentioned in the paragraph below the one you quoted. But my quote still remains a valid concern in that you can combine the keys and decrypt once, so you still have another point of attack; you can focus on the random sequences instead of, or as well as, on the data.

But your additional passes based on the individual letters are not very strong. If you have a text password, each letter only contributes with roughly 6 bits of entropy assuming upper and lower letters and some common symbols. In your case, 8 XOR passes with a 6-bit key is not a lot.

##### Share on other sites

I think i see what you mean. so 6 bits * 8 chars in this case would give 48 bit of entropy for the key?

I also read somewhere in an encryption book that it dosen't matter if an attacker know your algoritm as long as your data is well encrypted with a proper key, it should't be crackable.

Edited by Vortez

##### Share on other sites

I think i see what you mean. so 6 bits * 8 chars in this case would give 48 bit of entropy for the key?

Effectively, yes. You also have to remember that you lose entropy because of the fact that the first 32-bit key uses the same password source as the subsequent passes. In fact, it may even render the initial pass useless if I'm thinking correctly about this, since, given a set of 8-bit keys, there can only be one initial 32-bit key.

##### Share on other sites

As you said for encryption to be secure you have to assume that the attacker knows the algorithm.

Also 32 bit sounds like an awful trivial secure key.  Considering something like RSA which has been around for over 35 years uses keys over 1024 bit in length.

##### Share on other sites

Well, as i said i use multiples 32 bits hash keys (that i get from 1 string and n number of bytes making the string), so that must help i guess, im not trying to make a flawless encryptor, just something to prevent most people to intercept and decrypt my data and files, it dosen't need to be "military" strong encryption. I just find the algorithm pretty cool, work way better than my old add, shift rotate ect cypher which was flawed(since you could still guess what was in a picture after encrypting it), and can't find anything similar on the internet either. What i love about it is that it produce, for the first time, truly random data that i believe cannot be deciphered without knowing the algorithm. Im sure nobody except people with good knowledge of cryptanalist could decipher it using brute force alone. Of course, if the algorithm is known, then it's another story...

I'll try to post some pictures if i can find the old algorithm later to show what i mean.

Edited by Vortez

##### Share on other sites

You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.

If all you are after is a simple protection from the average user, then a single XOR pass with a PRNG seeded by a 32-bit hash of the password is probably more than enough for what you need. Who knows, it may even be enough to just rename your image.png to image.whatever and skip encryption entirely and get away with it.

You also have to be aware of one more thing if the intent is to protect game assets. If you, for example, upload your image as a texture, then it is quite a trivial task to intercept the data itself as you pass it to, say, OpenGL. No amount of encryption will help you here, since the OpenGL API provides only unencrypted data transfer.

Edited by Brother Bob

##### Share on other sites

and can't find anything similar on the internet either.

You must not be very good at searching the Internet. It took me about 20 seconds: http://en.wikipedia.org/wiki/Stream_cipher

##### Share on other sites
Oh, there is also a Wikipedia page on the weaknesses of this type of encryption scheme: http://en.wikipedia.org/wiki/Stream_cipher_attack

##### Share on other sites

You have to keep one thing in mind; it's not the bit length of the hash that is relevant, but the entropy of its source. If the source has less than 32 bits of entropy, then so will the hash. If you take the hash of every character of your password individually to get a set of keys, then each key has no more than 6 bits of entropy even if you calculate a 32-bit hash from it, since those 6 bits can only possibly generate 64 of the roughly 4.2 billion possible 32-bit hashes. One possible idea here could be to split the password into sets of 6 characters (6 characters then providing 36 bits, just above 32-bits for a hash), and do as many passes as you have 6-character sets.

Yea, i agree this should be improved, i wrote this thing in a day, about a year ago, so i might need to fiddle with it a little more. And the only 2 things i could think of to use it would be for files and network encryption.

And thx for the link Alvaro.

Here's the examples pics i was talking about:

This is the original image

This is the encrypted image using my old code (this is the best i could get before, and the first version was wayyy worst)

And this is the encrypted one using the new algo descripted above

hehe you could see the patern in the old code pretty well, at the time i tough it was fine... until i checked it out this way.

Still pretty good for something home made i guess.

Edited by Vortez

##### Share on other sites

Did i just find by accident the best encryption algoritm you can write?

No.

@Avaro or Vortez: also Block Cipher Chaining is also something very similar.

If you are really that interested, I can ask my Cryptology professor (I hope that's the word in english and not some strange religion) how breakable your algorithm is, but I would guess that it is pretty bad even compared to RSA. (Today, nobody would be using RSA encryption, there are just too many problems with it. But it is widely used, so until somebody comes up with the death strike for RSA. That happens as soon as the quantum computers can factorize bigger numbers).

Let's examine quickly where your cryptographic power lies: You generate a hash from your password. No power is hidden here, it is the same as if you would use a random 32 bit value.
Then you create a pseudo random number with the Mersenne Twister. After that you make an XOR operation with the pseudo random number. So your whole power lies in the strenght of Mersenne Twister. I don't now much about it, but it isn't used in cryptography because the next pseudo number can easily be guessed when you have some.
Plus as the link suggests, when you reuse a password, you are pretty much done, which isn't a very useful cipher in the modern age.

There is a reason why you tend to have a bachelor in mathematics before you specialize in Cryptography. While it can happen that you find the next super cipher, the chances that you do are very slim.

There are a LOT of ciphers out there that can fit your need, RSA, modern DES algos, even modified Vignere Ciphers may be more secure. For a Programmer, there is absolutely NO reason to not use a standard cipher. They have been very well researched and are VERY secure ("the hidden world" may know how to break it, but that is always a chance for people like us).

Edited by Bluefirehawk

##### Share on other sites

Getting the numbers from a pseudo-random number generator and using it for an endless xor "encryption" is pretty much the first thing ANY novice programmer comes up with(because the is no complicated algorithm involved) and it is bad because these numbers are not truely random (just barely random enough for feeding them into a game).

I get the feeling this thread was probably made to show how clever a technique that is, which it is not and OP is more focused on defending it than listening to better alternatives people repeatedly told. Its a weak cipher and you cannot improve on it much. Please do yourself a favor and find a real encryption algorithm thats tested already and use that.

##### Share on other sites

Having sat through a course and done all the math and derivations for graduate level cryptography, I strongly suggest you learn the basics of cryptographic functions and how to reason about them in a rigorous way. The symmetric stuff isn't that difficult. There are a lot of issues even in the responses here; I don't want to call anybody out in particular but there are way more fundamental issues involved than entropy. Consider something like Bruce Schneier's Applied Cryptography as a good introduction to the field that can be had for cheap.

Some basic problems that are notable immediately:

* We don't have a working definition of what constitutes secure.

* Mersenne Twister isn't a cryptographically secure RNG and is thus highly inappropriate for this type of use.

* The mathematical properties of XOR make the multi-pass thing totally ineffective, as mentioned previously.

* XOR the whole message against some value is guaranteed to return some correct bytes of the message.

Edited by Promit

##### Share on other sites

As you said for encryption to be secure you have to assume that the attacker knows the algorithm.

Also 32 bit sounds like an awful trivial secure key.  Considering something like RSA which has been around for over 35 years uses keys over 1024 bit in length.

It's not really comparable that way, RSA is an asymmetric cipher. The thread is about a stream cipher. Apples to oranges.

But I agree that the security of the discussed cipher is trivial.

##### Share on other sites

Im not saying that i don't want to use another known and tested algorithm, i just wanted to know the most noticables things i could improve this algorithm on.

In fact, i've found a simple aes-256 bits algorithm in c, and might include it in my own library later too.

What i meant is, unless a cryptographier tried to decript my files using my encryptor, which is nobody i know of in the remote area where i live, could crack it. Hell i've made it and couldn't even crack it given lots of rounds. But i get your point. The government would probably crack it fast enough...

The thing is, my goal with this code is more about speed than security, if im worried about security, then ill use a well known method in this case.

The only thing i ever cracked this way was a simple xor algorithm of jpeg files on a cd with each byte encoded using 1 pass and the same xored value everywhere haha.

After i've found the first 4-5 bytes it was rather easy... But then on another cd they used more round and/or more xored value and then i gived up. That was a long time ago though, like 15 years ago. That just about the level of security im after, something not too simple, but not too complicated too so it take a long time to encrypt, and can deter most noob attackers like me.

Edited by Vortez

##### Share on other sites
Also, I would like to point out that you can't evaluate how "noisy" an image is just by looking at the distribution of values. This is because noise is characterized not by a specific distribution of values, but by a lack of correlation between subsequent values. For example, an 8-bit sawtooth waveform has the same distribution you describe - all values equally likely - yet is not at all noisy because every value can be completely predicted from the preceding value. Conversely, a stream of values where every value is the sum of 5 random numbers is very noisy - as there is no correlation between subsequent values at all - but the values themselves fall into a normal (i.e. Gaussian) distribution.

##### Share on other sites

Actually, now when I think about it, your algorithm is much worse than that. Since you only encrypt a byte at a time, and the sequence of random numbers is fully known, you effectively only have a 8-bit XOR cipher. Not only is brute force viable, but even manual brute force BY HAND is viable since you effectively only have an 8-bit key and thus 256 combinations to manually examine.

There's a flaw in that reasoning...

Think of the "one time pad" encryption scheme. In the one-time-pad scheme, you have a seemingly random sequence of essentially infinite length to encrypt the data with. Now, you need only encrypt one byte at a time, heck even 1 bit if you like, and this is known to be uncrackable. It's essentially a key of infinite length, or rather the key is as long as the data.

Now relating that back to the proposed scheme here...
The sequence of random numbers is only "fully known" in the sense that the PRNG does eventually repeat its sequence, and so the key length is not infinite. But with the PRNG chosen here, that sequence is extremely long, and would not repeat for the length of the data being encrypted, making it effectively as secure as the one-time pad in that respect. However, the weakness is that where is starts has 2^32 possibilities. Basically you don't really know the sequence at all, but you it is one of X possible sequences.

Calling it effectively an 8-bit key is thus very much incorrect. Your earlier post about the key being 2^32 in size was correct though, because it's like choosing between 2^32 keys of a very long length.

Oh and this entire idea is not new to me, not in the slightest, although I never did bother implementing it yet.
Personally I would use a larger seed. Good PRNG algorithms have an internal state that is much larger than 32-bits. XORShift for example has 128 bits internally, and I'd probably use that and initialise all 128 bits to a 128-bit hash of the password, if I were doing this.
I'd also XOR 32-bits at a time, not because it's more secure, but because it's more efficient. Edited by iMalc

##### Share on other sites

Unasked but often most important:   WHY?

Why are you doing this?

Encryption is a method to protect data in transit between good actors through a hostile environment.

As a simple example, a secure web page only makes it difficult for an eavesdropper to listen to your web traffic and read the results in the clear.  This is only a good thing if both ends are good actors.  It provides absolutely no protection if the web browser or computer is being operated by the attacker.   The web page can be encrypted with the strongest protections in the world, it doesn't make it secure against somebody looking at the screen, or against somebody with spyware installed on the machine.

You don't describe a situation of two good actors.  You have a bad actor (the person performing the attack) who has access to the running the game code.  This is not a thing that encryption will protect.

It looks like you are encoding your resources.  Why?  Any attacker can simply stop your game in a debugger.  They can watch for you to decode the data.  And once it is decoded they have full access to the content.  The attacker can also copy the decyrption code and run it directly on the content themselves.

If you are talking about using this for protecting your network data stream, again, why?  An attacker can do exactly the same thing as above, establish an encrypted communication stream, and then read the clear communications as it is decoded on their side.  The real benefit for encryption online is to make it so good actors cannot have their communications monitored or modified (depending on the cyphers used) by bad actors.  The bad actors can look at the protocol, and they can see everything that is going on in their own sessions, and they can even send corrupted communications on their own secure connection.  A bad actor can still establish their own secure connections, and they can still engage in their own transactions; that is not what encryption does. The point of encryption is that even with full knowledge and with full network access a bad actor still cannot directly intercept and harm the communication of two good actors.

So what are you trying to protect, and why?

Edited by frob

##### Share on other sites

Well, im simply trying to find a way to encrypt the data that pass through the network of my RemotePC project, for example, a kind of VNC so easy to use that even my mother can use it, everything work fine, it's a finished project, i was just wondering if i should change my encryption scheme. Im mostly trying to hide the handshaking part of the connection, along with screenshots and keypress, mouse events ect. Of course im assuming that both side are "good" actor otherwise encryption is pretty useless. Im more concern about what they call the "man in the middle" attack, like someone sniffing out your packet, although firewalls pretty much eliminated most trojan based virus. Im not saying that a firewall is infallible but that it does a pretty good job at what it do. Im pretty sure an attack on my software, which only me and my mother own is almost inconsivable, it just make my mind feel a little better about it. By encrypting the data, how could they guess the data transfer protocol?

And i also wanted to make file encryption more random-like, instead of leaving a "trace" of the original image, as i was saying so, at the very least, an average hacker at the file couldn't guess what's inside, defeating the encryption in the first place.

Im fully aware that my code isin't very secure, i just do this to experiment mostly. I might try other tested encryption technique too when i have the time, i just love to do everything in my projects by myself, that's all.

Edited by Vortez

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

• ### Forum Statistics

• Total Topics
628362
• Total Posts
2982266

• 10
• 9
• 13
• 24
• 11