Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


What do you think of my encryption algorithm


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
30 replies to this topic

#21 Vortez   Crossbones+   -  Reputation: 2704

Like
0Likes
Like

Posted 19 April 2013 - 03:26 PM

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, 19 April 2013 - 03:34 PM.


Sponsor:

#22 Anthony Serrano   Members   -  Reputation: 1224

Like
0Likes
Like

Posted 19 April 2013 - 03:48 PM

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.

#23 iMalc   Crossbones+   -  Reputation: 2313

Like
0Likes
Like

Posted 19 April 2013 - 04:07 PM

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, 19 April 2013 - 04:12 PM.

"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

#24 frob   Moderators   -  Reputation: 22293

Like
2Likes
Like

Posted 19 April 2013 - 04:44 PM

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, 19 April 2013 - 04:52 PM.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.


#25 Vortez   Crossbones+   -  Reputation: 2704

Like
0Likes
Like

Posted 19 April 2013 - 05:53 PM

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, 19 April 2013 - 05:59 PM.


#26 MichaelNIII   Members   -  Reputation: 195

Like
0Likes
Like

Posted 19 April 2013 - 05:54 PM

I know its been said a ton. But they are right. I will disagree that working on your own cyphers is a bad thing. More so because of your understanding will be worth the mistakes. However if you need to be able to undo the cypher on the users computer then it kinda is pointless. If you are trying to make sure they can't use false files for your game and are encryting them oddly to keep people from making alternative textures - stop, this isn't the way to go. I would suggest getting a md5 or such of the file, and then when you load the image check to make sure its md5 is the same as the one distributed with the program. This is hackable, however is a much better alternative.

#27 ApochPiQ   Moderators   -  Reputation: 16079

Like
0Likes
Like

Posted 19 April 2013 - 05:55 PM

Just use a known asymmetric encryption scheme. Secure network transmission is a well-explored problem, and believe me when I say you're just begging for someone to come along and break your attempted encryption in a matter of minutes of reverse engineering.

#28 xGummy   Members   -  Reputation: 114

Like
0Likes
Like

Posted 19 April 2013 - 06:39 PM

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 agree it's better to use an existing algorithm if the goal is to actually secure data.  But if the goal is to play with cryptography and learn, then doing your own stuff is fun and educational.  But, in that process, also learn as much as you can because starting out, what you're trying is bound to be the simplest possible way of doing things... and hence the most unsecure.



#29 Vortez   Crossbones+   -  Reputation: 2704

Like
0Likes
Like

Posted 19 April 2013 - 07:30 PM

So what algorithm would be fast AND secure enough for this kind of thing? (network encryption)


Edited by Vortez, 19 April 2013 - 07:31 PM.


#30 Bacterius   Crossbones+   -  Reputation: 9100

Like
0Likes
Like

Posted 19 April 2013 - 08:33 PM

So what algorithm would be fast AND secure enough for this kind of thing? (network encryption)

 

SSL/TLS with a decent cipher suite.

 

There are an immense number of pitfalls you can (and will) fall into if you try to design your own encryption algorithm and protocol. A few of them:

- inadequate privacy, this just means your cipher sucks and can be broken by simple cryptanalysis or brute force

- inadequate integrity, someone can modify your stuff in transit and you haven't implemented secure checks for this

- inadequate authentication, someone can impersonate whoever you are trying to communicate with (by intercepting the TCP connection and imposing himself as a middle man) and you wouldn't even know

- replay attacks

- weak password exchange schemes

- side channel attacks

- reverse engineering

- and a thousand more threats you and I cannot even begin to conceive

 

Also, in cryptography, you always prepare for the worst. Saying that only you and your mother are going to use the application is *not* a valid argument. If that is the case, and you are not anticipating anyone trying to attack your protocol, why even bother? You may as well do nothing at all, since you don't know what you are going to defend against. Otherwise, you need to set up a realistic threat model (for instance, I agree it is unlikely your protocol will be targeted by an APT - advanced persistent threat, that's stuff like governments and security agencies - but a lone bored hacker might come across your router, scan it, find an open port, eavesdrop on your protocol, learn it, break it, and then start doing lots of damage).

 

With some cryptography training it is plausible to create your own limited, specialized cryptographic high-level protocol for when nothing else really works, but is still requires a lot of work and peer review, and that does not include whole ciphers and hash functions. If you do that for anything other than learning and fun (which is a fine goal in and of itself, by the way - cryptography is fascinating), then you have failed as a responsible developer.


The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#31 frob   Moderators   -  Reputation: 22293

Like
0Likes
Like

Posted 24 April 2013 - 03:43 PM

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.

 

If learning is the goal, go read books like Applied Cryptography by Bruce Schneier.

 

You will learn far more by reading books about crypto than by toying around on your own.


Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I write about assorted stuff.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS