Please, just use an existing package instead of writing your own easily breakable ecryption program. There are so many freely available libraries that you would have to be insane to want to code it yourself.

Quote:

Original post by hplus0603 Quote: FireNet: The encryption algorithms mentioned are a bit complex. No, in fact, TEA is one of the simplest algorithms there is, apart from XOR. Meanwhile, TES is cryptographic strength, and XOR isn't. Just for completeness, the source code for X-TEA is here: *** Source Snippet Removed *** You may note that it's block-based; I mistakenly suggested it was stream based in my previous reply; it's the key-mutating versions of (X)TEA which are stream-based. The basic, block-based algorithm shown here is much more suitable for a lossy network. Quote: FireNet: key based algorithms are complex so if you cant implement or plug them into your code you could use simpler encryptions which are password based There is no difference between a "password" and a "key". If you think a "password" is a sequence of ASCII characters, and a "key" is an arbitrary sequence of bytes, then you can easily turn a password into a key (concatenating byte values), and vice versa (think uuencode). Perhaps you meant to say "public key based algorithms"? If so, it still doesn't make sense, because nobody had suggested a public key cryptosystem before your post.

Well hplus0603, you screw me for nothing.I never said all the algorithms were complex.I was thinking of PGP,RSA,Blowfish etc.And anyway just because I think some algorithms are complex it need not be complex for someone else.And just be cause some post says something contradictry to another (as long as both/one are not wrong), we are not doing 1+1 or 1-1 like a comp. We are humans after all.We can thing "illogically".Brrr.Please try to get the gist rather than at the individal stentences or words.

Quote:

Perhaps you meant to say "public key based algorithms"? If so, it still doesn't make sense, because nobody had suggested a public key cryptosystem before your post.

Well I did mean "public key based algorithms" by key.And btw then if no one suggested a public key based algorithm then what the post by evolutional on PGP

Quote:

Original post by evolutional PGP [www.pgp.com] relies upon public-private key encryption which is useful in messaging. However, you'll need to ensure that the client and server have both public and private keys, making it......

If that can only be seen on my comp or it just a random trick by windows on me then I am very sorry.

BING!!!!

P.S:I dont have an always on internet connection to give too detailed answers all the time and much is more opinion than fact or info.Modern life is too much of a hurry.

[Edited by - FireNet on July 23, 2004 8:11:19 AM]

some links:

Blowfish:
www.codeproject.com/cpp/blowfish.asp

Misic:
http://www.thefreecountry.com/sourcecode/encryption.shtml
http://www.xceedsoft.com/sitemap/Encryption-Library.htm


Hey just go to:
www.google.com
www.theoma.com

You will find code and tuts on this stuff.But it takes a bit of looking to find good stuff and it's fun.You will find a lot of it,new stuff i.e if you do the searching yourself.

This isn't a good place to ask that question. Try sci.cryptography (and especially, the sci.crypto FAQ) :o)

The best I can do : you must somehow convey to the recepient the seed you will both use, or they can't decrypt it any more than your enemy. If you are able to transmit the seed (effectively a key) securely, then why not use the same mechanism to transfer the information?

If you plan to hand over the key in person and send the information later, then that's fine, but you can only use it once. If you use the same key twice in this manner you would be stuffed. If it is a truly cryptographically secure random number generator, what you have is effectively a one time pad.

Public/Private key pairs are designed to allow insecure transmission of a key without compromising the security of the message.

In the world of computer games, you cannot sensibly be cryptographically secure (you could prevent clients of your server snooping on each other (spying), but not a client intercepting the data being sent to or by him on route (cheating)). Your best bet here is something which makes life as awkward as possible.

That's because the internet is designed that way.All data sent on the internet passes through several computers.

In Unix and Linux you get to control almost everything (root) and if someone wants to sniff all the packets he/she gets, they very well can and will.It not too difficult.And if someone gets on a router it's even worse.

So if your best bet is public-private key based encryptions, but even that can be bad if everyone shares the key sets.Your choice and how sensitive is the data matters (only?).

Btw,I dont really feel it's worth the processor time it take to encrypt small data packets with public-pivate key based stuff when simpler encryptions like XOR can be used.

These can be cracked but it will take too long,that it will be useless by the time it decrypted.Even if it take only lets say 20-30 secs,by that time lots of changes will happen in a network game and the cracker may not be able to even play since he has to devote lots of processor time to craking.

So you can see we really dont need complex encryptions which are used to encypt emails.Simple ones will do just fine and will be secure till the data becomes useless.

Also any encryption can be cracked given enough time (even more than a million years) so we really only have to worry about protecting the data while it is useful.

So for a serve/client game you could use some form of a dynamic password, with a simple encryption like XOR.

By dynamic password I mean with every pass of data a random byte can be added or subtracted on any side and this change can be sent to the other side encrypted with the old pass and the other side will change the pass again and send it to the first side with the modified pass the first side sent.

Ok it not very clear but look at the diag..


In this system it's not neccesary to send the whole pass,rather just send the info on which byte has changed and by what value.That way tha pass keeps changing and really no one will be able to get anything other than the correct client.

But then again if someone manages to get hold of the initial unencrypted tranmission where the server and client set a initial password ,then it is possible to follow their communication.If even one packet lost by the sniffer then he can say bye bye.And it take a huge amount of proccesor time and enormous memory to do sniffing and even then packets can be lost by a sniffer.And if a router own by an ISP is hacked, it will be found at once if someone tries to sniff all the packets.So much of this is only theoritically possible but not immposible.

Then again security was always an oxymoron and it's a process not a goal.

Hope this give you some idea as to what to do.And dont worry too much ok :)

[oh,XOR takes a very long time to crack with brute force or even a dictionary.So if you use a mix of the ancii chars (like: @$$@$sda9898$hh) only brute force can be used and it will take hours (day,weeks).I said 20-30 just to illustrate that even a short time passing will cause the data to be useless to be of use ;-)]

[Edited by - FireNet on July 24, 2004 12:06:04 AM]

I suggest going to the authorities on key management, because it's as sensitive as the actual encryption technique. For example, the method suggested by FireNet will make immediate key recovery slightly harder by a mediocre attacker, but it's by no means actually secure. For example, if the attacker has a transcript of the entire session, he still knows as much as the client. There are also ways the attacker can use the key mutation information to actually recover the key, even if the mutation is key-relative (somewhat depending on the cryptosystem used). For an example of spectacularly bad key management, look at WEP (used for WiFi networking) -- you can easily crack any WiFi network, because of some poor design choices related to key management.

Luckily, there DOES exist a mechanism to securely exchange a key, in the clear, in a way such that no bystander can know what the key is, but both ends of the exchange do. The mechanism uses trap-door mathematics on both sides and exchanges intermediate hashing state that allows both sides to compute the same key, based on random numbers secretly known only to each of the sides. Google for "Diffie-Hellman Key Exchange" for more information.

And, just like public/private key encryption, using a mechanism like this is likely way overkill for most games. But if you can find a library that already does it, and can pay the runtime cost, it might be worth it.

True,that method just tries to make key recovery difficult by making it time consuming to get hold of the key.A few secs will make the key along with the new key useless as it is always changing.

As I said earlier,simple encryptions will do very nicely keeping your data safe enough.

Also the chances of a random attacker getting hold of you packets is very,very slim.It's very difficult.The other possibility would be that atttacker and target are on the same lan.Then it is possible to spy by various methods like ARP poisioning,sniffing the router etc.It's very hard to stop an enemy if he & you are on the same ship.
Anyway rather than decrypt client/server transmission,it's much easier to just shift a few bytes and cause problems.Or even send FIN packets to close the connection.An attacker on the net can accomplish the same using DoS tools.

So for small transmissions the method is secure enough and cheap.

Why worry too much anyway?Security was always an Oxymoron