What do you think of my encryption algorithm

Started by
29 comments, last by frob 10 years, 11 months ago

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

Advertisement

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.

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.

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.

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.

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?

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.

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.

The golden rule for programmers producing their own encryption algorithms is "DON'T". Anything you produce is likely to provide very poor security. Just pick one of the established algorithms designed by cryptography experts that's easy to implement (like XTEA).

Unless of course you're interested in cryptography. In which case you're better off studying the existing algorithms and what makes them effective rather than trying to come up with something new from scratch.

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.

This topic is closed to new replies.

Advertisement