• 13
• 18
• 19
• 27
• 9

# How to implement a Symmetric Key Cipher

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

## Recommended Posts

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.

##### Share on other sites
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.

##### Share on other sites
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.

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
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).

##### Share on other sites
whats wrong with using RSA? its fast.

##### Share on other sites
Quote:
 Original post by ibebrettive done it for project euler http://projecteuler.net/index.php?section=problems&id=59quite 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.

##### Share on other sites
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.