Encryption - is this a good solution?

Started by
8 comments, last by seanw 19 years, 7 months ago
Hey. I'm making a (very) small encryption tool that allows people to encrypt a file to secure its content.

char input = 0;

	while (1)
	{
        strfilein.read(&input,1);
		if (strfilein.eof())
		{
			break;
		}

                //xor the input char with every character in password
		for (unsigned int i = 0; i < strlen(password); i++)
		{
			input ^= password;
		}

		strfileout.write(&input,1);
	}
Is this a good solution, to: read 1 char xor it with every character in password string write the char to a new file repeat the whole thing until eof. Is this very easy to crack, or is it reasonably secure? Thanks in advance :)
Advertisement
It's not very easy, but extremely easy to attack.
You're basically xor'ing every byte in the file with a constant value ((A xor B xor C xor D) == (A xor E), for some E). Without even knowing the password, you only need to check 256 possible values for this constant.

If you really want to encrypt a file, don't try to invent a new encryption algorithm. There are plenty available.
Quote:Original post by ziggwarth
Is this very easy to crack, or is it reasonably secure?


As with most encryption the longer the key (password) the harder it is to hack. XOR is the simplest encryption, but therefore is also the easiest to hack. If you just want to stop someone reading a small text file it is probably fine.
If you want an easy symmetric algorithm, I would suggest looking into RC6. It was one of the last 5 candidates for the AES. It's very secure as well as being fairly easy to implement.

etran1
You could always use TEA.

Enigma
Thanks for enlightening me. :)
I'll definitly check out some of the suggestions here.
I'll put a second vote in for TEA.

What you wrote above is horribly inefficient. You could have pre-computed the xor of all the characters in the password and then done 1 xor per character.
There's only a certain amount of entropy you can produce when your chunk size is 1 byte, and nothing is carried across to the next chunk, no matter what the key-length or algorithm.

What's worse is that if you used certain passwords in the code above like "ABBA" then your data would come out unchanged and unencrypted.

Edit: Anyway, to answer your question... No it is most definately not a good solution by any means.

[Edited by - iMalc on September 22, 2004 1:09:00 AM]
"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms
Just a few points:

AES (Rijndael-128) is the current accepted standard for most encryption. Rijndael-256, and Rijndael-512 offer stronger encryption as well.

There are opensource Rijndael implementations which offer multiple encryption modes.

You will probably want to use an encryption mode such as Cipher Block Chaining (CBC) mode or Cipher Feedback (CFB) mode to ensure that like blocks of plaintext do not encrypt to like blocks of cipher text.

The handbook of applied cryptography is a VERY good resource to learn about encryption. You can read the chapters online, but it is definately worth the purchase.

XOR based encryption is highly unreliable unless you are using some kind of sequence generation; for an example of a relatively good implementation of a xor based encrytion algorithm look up RC4.

The algorithm you describe above is incredibly weak against even the most basic cryptanalysis.

Also remember to securely delete your keys from memory when you are done with them, (i.e. use memset to zero the memory address holding the key). The current NSA standard (iirc) is to overwrite data 7 times when securely deleting information from a hard drive; overwriting it 7 times with encrypted random data is the implementation a colleague uses regularly. It may seem paranoid, but being paranoid is my job ;)

hope this helps..

Yvan
If you want to keep your algorithm small, you could easily implement some sort of bit generator such as a stop-and-go generator with 3 1KB LFSRs or a quadratic residue generator. A stop-and-go generator based on 3 1KB LFSRs will have a maximal length of repetition of appx... 2^3072-3*(2^2048)+3*(2^1024)-1, which for all intents and purposes is 2^3072, but will require 3072 bits of key information (which isn't really that much), which means your data would be secure from key repetition for 2^3072 bits, which is a lot of bits. I haven't cryptanalyzed the quadratic residue generator recently, but it's more secure than an LFSR with less work. You xor each bit with a uniquely generated key bit from the bit generator, output the generated key to the screen and have the user use the randomly given password to secure their data. Decryption would be the simple A + B mod 2 case. If you'd like some help designing a system like this let me know.
Quote:Original post by ziggwarth
Hey.

I'm making a (very) small encryption tool that allows people to encrypt a file to secure its content.


Unless you're doing this for fun or something, there are plenty of tools out there with years of cryptography research behind them that will be infinitely more secure than a program you can write in a couple of hours. Try looking at PGP for one.

This topic is closed to new replies.

Advertisement