What do you think of my encryption algorithm

Started by
29 comments, last by frob 11 years ago

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.

Advertisement

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.

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.

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
Oh, there is also a Wikipedia page on the weaknesses of this type of encryption scheme: http://en.wikipedia.org/wiki/Stream_cipher_attack

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.

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

Project: Project
Setting fire to these damn cows one entry at a time!

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.

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.

SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.

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.

This topic is closed to new replies.

Advertisement