Archived

This topic is now archived and is closed to further replies.

Userdata encryption...

This topic is 5585 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Most simple ciphers i''ve seen simply change a fixed binary sequence into another both of equal size. For example: In plain text :Hello! In Cipher text :ADGR4T From what i understand, to crack one of thoose you could simply brute-force the cipher. But what if i also changed the size of the ciphertext like "Hello" would become "09403239Ad323412" Instead of the equal sized "ADGR4T" (we are prepared to accept the increased datasize). Wouldn''t that make it alot harder to crack the cipher? Math genius? Give me the combinatoric figures please. I did some background reading on RC4 & MD5 but thoose are faar to advanced for my needs. I just want to keep "joe average" from loading user data in your "joe average" hex edit. ______________________________ Only dead fish go with the main-stream.

Share this post


Link to post
Share on other sites
A skilled attacker might not even notice.

You usually don''t ''brute force'' a substitution cipher, you run a frequency analysis on it. When you write your general purpose frequency analysis tool, if you''re smart you wrote it to operate on substrings and not single characters. Ciphers just plain suck in general: don''t use them.

If you''re trying to encrypt a game data file I doubt you''ll be dealing with such a sophisticated attack, though. What you''ve got is probably fine.

You might want to think about using blowfish or DES, though. Sample source for the implementation is freely available around the net.

Share this post


Link to post
Share on other sites
I''ve found DES or even Triple-DES are relatively simple to
implement. the NIST website has information on DES. http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf

Share this post


Link to post
Share on other sites
Yes if U rise the size of crypted char U will get crypted data that is harder to encrypt withouth key, (in numbers if 1char->1 char then U have 256 posibilities for each char, if U have 1char->2char then U have 256*256 possibilities for 1 char)but if U will change 1char to 1-2 chars( example from ''a'' it will be "D" and from ''b'' it will be "2K") then it''s uncomparable hard to encrypt to first method, but if cracker find the algorithm that cryptes or decryptes then he can decrypt almost every crypto algorithm in few seconds... If U don''t hide the code for crypt then U don''t need IMHO more then 1char->2chars...
Glubo The Mad

Share this post


Link to post
Share on other sites
Actually, in an ideal (unbreakable) encryption scheme, the length of the cyphertext and plaintext are *equal*, you just change the "key" (whose length is always the same as the plaintext''s) each time you encrypt. This is known as a one time pad, and, yes, it is theoretically impossible to crack (considering you have a truly random set of keys).

Block ciphers (DES, Blowfish, AES, et al.) do not inflate the size of a block of data; they merely perform a series of nonlinear substitutions (not unlike an extremely, extremely advanced Enigma machine). More likely than not, ciphertext size is going to be smaller than plaintext size, as you more than likely ought to run your plaintext through a compression algorithm (so as to eliminate some redundancies which would otherwise possibly ease cryptanalysis). Public key cryptosystems, on the other hand, do result in a size increase, though this is due to the need of multiplying chunks of your plaintext with extremely large numbers.

If you want a good symmetric cipher, IDEA is my (and many others'') favorite; it is, however, patented. Blowfish, Twofish or AES are great alternatives (though it would seem that AES is slightly more vulnerable than Blowfish or Twofish; no attack has been found that compromises it in more than four rounds to my knowledge, however). Stay away from DES at all costs. A 56 bit key is *SO* not secure. There are specialized machines that can exhaust DES''s keyspace in a few hours.

Share this post


Link to post
Share on other sites
One more thing: block ciphers can essentially serve as OTPs if the length of the plaintext is less than that of the unicity distance of that cipher, which is more or less a function of the key length. I believe English text has 1.3 bits of data per bit of text, so, with, say, a 128-bit key, you get about 100 characters. Assuming you use different keys. Niner.

Share this post


Link to post
Share on other sites
Err, if you want a simple encryption scheme to break joehax0r, try this. I'll make the basic assumption that the game data is prearranged into an array of unsigned chars before being fwrite()ed to where ever. Also, I'm going to assume that the FIRST byte in this array is the "Checksum" character, meaning, that it has no useful purpose ingame, just it works with the data to prevent messing with. It doesn't have to be the first nessesarily, just has to be there somewhere.

unsigned char gameData[ GAMEDATALENGTH ];
int x
unsigned char checkSum;

gameData[0] = 0;
y = 0;
for (x=1; x < GAMEDATALENGTH; x++) { gameData[x] = ~gameData[x]; y+=gameData[x]; }
gameData[0] = (unsigned char) 256-y;

What this code does is toggle every bit in the data. The checksum is then defined as the inverse sum of the gameData. What this does is after loading this data later, you can do a quick check to see if joehax0r messed with the data.

for (x=0; x .LESSTHAN. GAMEDATALENGTH; x++) { y+=gameData[x]; }
if (y) { fprintf(stderr,"BIG TIME AMERICAN HACKING ERROR!");

and then you can decrypt the code the same way.

for (x=1; x .LESSTHAN. GAMEDATALENGTH; x++) { gameData[x] = ~gameData[x]; }

I'm pretty sure that works. Its simple enough, but that also means its very easy to crack.

(edit: where it says .LESSTHAN., I mean the lessthan sign. just I don't know the gamedev.net codes for not interpreting html)

-> Will Bubel
-> Machine wash cold, tumble dry.




[edited by - inmate2993 on August 28, 2002 4:50:04 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by Ekas78
Most simple ciphers i''ve seen simply change a fixed binary sequence into another both of equal size.

For example:

In plain text :Hello!
In Cipher text :ADGR4T

From what i understand, to crack one of thoose you could simply brute-force the cipher.

But what if i also changed the size of the ciphertext like "Hello" would become "09403239Ad323412" Instead of the equal sized "ADGR4T" (we are prepared to accept the increased datasize). Wouldn''t that make it alot harder to crack the cipher?

Math genius? Give me the combinatoric figures please.

I did some background reading on RC4 & MD5 but thoose are faar to advanced for my needs. I just want to keep "joe average" from loading user data in your "joe average" hex edit.

______________________________
Only dead fish go with the main-stream.


One way you could achieve the same without having to cypher is to simply put a checksum in your dat file and validate against it. That way, if the file is modified in any way, the checksum validation fails.

There''s an article about that somewhere here. I don''t remember where but I remember reading it.

"DaHjajmajQa''jajHeghmeH!"

Cyberdrek
danielc@iquebec.com
Founder
Laval Linux

/(bb|[^b]{2})/ that is the Question -- ThinkGeek.com
Hash Bang Slash bin Slash Bash -- #!/bin/bash

Share this post


Link to post
Share on other sites