How to implement a Symmetric Key Cipher

Started by
11 comments, last by Mantear 13 years, 4 months ago
Recently, I've been looking into ways to encrypt and protect my files. I've always kept hashes of my files to verify their integrity, but now I'd like to encrypt them as well.

The first method that came to mind (since I will be the only one encrypting or decrypting) was to XOR the files bit-by-bit (or byte-by-byte depending on how the i/o stream works) with some key. Basically a Symmetric Key Cipher.

I'm not sure how to generate the key though. Could I just use a password-length key and do the following?

for (i=0; i<length(plaindata); i++) encrypted = key[i%length(key)]^plaindata;


It seems simple enough, secure enough, reversible, and at first glance I don't see anything horribly inefficient about it.

However, I've never done anything like this before so I wouldn't be surprised if I was doing something silly or pointless.
Advertisement
its ridiculously insecure. if you encrypt a well known file type, i can attack using the certain magic strings contained within the file. if its source for cpp, good guess that the word "include" is used, etc.

How so?

I'm not using a single substitution cipher.

Where 'include' might be encrypted to one string, elsewhere it'd be likely with a probability of (key_length - 1) / (key_length) to be encrypted to something different.

I think you might have confused this method for a single substitution cipher which would have the flaw you're describing.
ive done it for project euler

http://projecteuler.net/index.php?section=problems&id=59

quite easily. unless im misunderstanding your scheme, and if so i apologize for the confusion
i will also note that you can break xor keys into pieces, so that if the work 'the' shows up in my attack. i can keep the key the same in that section that happened to overlap those letters, and change the rest. Normally you cant do that with most crypto systems. Basically breaking a small part of the key actually makes it easier to break the rest.
If you don't want to use a readily available cipher, you should read up on Feistel networks, which are the underlying principle of the majority of ciphers.

You should really consider using a well-known implementation, though. Implementing a fast cipher is trivial, and implementing a strong cipher is trivial. However, implementing a cipher that is both fast and strong is a hard problem (which is the reason why you would probably want to use a well-known cipher rather than making your own).
whats wrong with using RSA? its fast.
Quote:Original post by ibebrett
ive done it for project euler

http://projecteuler.net/index.php?section=problems&id=59

quite easily. unless im misunderstanding your scheme, and if so i apologize for the confusion


Yep. That problem is exactly the way I was thinking of doing it. My pseudocode in my original post did exactly that: repeatedly cycling the key due to it being shorter than the plaintext.

As for security, I don't really see any feasible way to crack this without knowing the key.

I considered RSA and I've studied it in the past, but this seemed much easier and quicker.

Can anyone point out an actual security flaw with this approach?

Most of the files would be in the 10 kilobytes range and the keys used would be roughly 64 to 128 bits.
what made it easy for me is, that you use a dictionary, and try permutations of the keys. now if you find a match the dictinoary anywwhere, leave those bits alone but continue permutation the rest. This is because the bits in the key and the bits in the encoded text match up. you can't do that with rsa. so as soon as a fine one 'the' in your text, 3 bits are taken off your key. i can breack it in small bits.
This is basically just a polyalphabetic substitution cipher. See here for more information and ways to crack it. It's a little different since you are working with whole bytes instead of just letters but it's the same general idea.

This topic is closed to new replies.

Advertisement