Cryptographic algorithm design

[Hiroshe]

Lately, I've been looking into cryptography, and I'm seeing if I can make a fun, maybe half-decent symetrical encryption alorithm. I am no professional, I've just seen a few algorithms online. I've came up with a few ideas:

Version 1) I started of with simple xor encryption. I've learned that xoring the cyphertext with the plaintext will give me the key. So to combat this why not subtract the text from the key first? example:

text: 10010110 10111110 10101101
key: 01110001 10101111 10000111
-------------------------------------------------
sub: 00100101 00001111 00100110

then:

sub: 00100101 00001111 00100110
key: 01110001 10101111 10000111
--------------------------------------------------
xor: 01010100 10100000 10100001

Question 1: Is this easily reversable?

Version 2) Then I thought that it might be more secure to do the subtracting stage in (2 bytes, 16 bits) rather than in (1 byte, 8 bits) like above.
Question 2: Is this more secure? Would it provide even better security if I used (4 bytes, 32 bits) on the subtraction stage?

Version 3) Lastly I thought that maybe I could expand the key, so it looks like the key is random (assumung the origonal key was truly random) and is the same size as the text. Something like below maybe?

1. Load the key into two variables: first key and second key.
2. Encrypt a keylength of text with the first key.
3. Rotate the first key 5 bits left.
4. Use version 2 (or 1, if the security is the same) on both keys, store on second key.
5. Encrypt the next keylength of text with the second key.
6. Rotate the second key 5 bits right.
7. Loop all but the first step until there is no more text.

I remeber seeing some kind of key expanding algorithm in rijndael I think.
Question 3) Is this anymore secure? That was just a last minute algorithm, but if you get another good key expanding formula, would the security be better?

[thoughtcoder]

Question 1: Is this easily reversable?

Yes. If you have the key, you can xor it and add it to get back the original plaintext.

Version 2) Then I thought that it might be more secure to do the subtracting stage in (2 bytes, 16 bits) rather than in (1 byte, 8 bits) like above.
Question 2: Is this more secure? Would it provide even better security if I used (4 bytes, 32 bits) on the subtraction stage?

It is not really more secure in any practical sense. You can still break the algorithm using the same idea used to break plain xor.

Version 3) Lastly I thought that maybe I could expand the key, so it looks like the key is random (assumung the origonal key was truly random) and is the same size as the text. Something like below maybe?

1. Load the key into two variables: first key and second key.
2. Encrypt a keylength of text with the first key.
3. Rotate the first key 5 bits left.
4. Use version 2 (or 1, if the security is the same) on both keys, store on second key.
5. Encrypt the next keylength of text with the second key.
6. Rotate the second key 5 bits right.
7. Loop all but the first step until there is no more text.

That's no good because the way the keys change isn't depending on the plaintext at all. If you encrypt multiple things with the same key, you'll give big hints about what's in the key. Also your algorithm seems to do nothing to the first key except rotate it, so it's as if half the plaintext, interleaved with the other half, is fairly easy to decipher.

I remeber seeing some kind of key expanding algorithm in rijndael I think.
Question 3) Is this anymore secure? That was just a last minute algorithm, but if you get another good key expanding formula, would the security be better?

As long as the key expanding formula only depends on the original key, (and as long as you just do something like xor and subtract) it's no good because you can't use the algorithm on multiple files without compromising security.

[Hiroshe]

I should have been a little bit more clear. Can version 1 be cracked without a key (The answer is probably yes) assuming that the information & key is random. Can the version 1 key be found if you have a cypher/plaintext.

The idea of version 2 was to make pairs of bytes relitive to eachother. Heres an example of what I mean: If you have a small key, say "ab" and a plain text "cdce" and it cyphers into "ghgi" on version 1, but on version 2 it cyphers into "ghqj" becouse you are not doing a byte by byte cypher. (I.e. the byte beside the byte you encrypt will change both bytes.) Is my methed of doing this (subtracting in pairs) a good (simple) way to do this? If you make the bytes subtract in pairs of 4 or 8, will it provide better protection?

Sorry about my messy algorithm on version 3, ill make a better example.

You get a key from the user, and the lenght of the message.
key: 12345
length: 15
You then make two key variables with the key value.
keya: 12345
keyb: 12345
You add the value to the first part of the "final key"
final key: 12345
You shift keya 5 BITS left, lets say
kaya: h2g4n
kayb: 12345
you encrypt both keys, add the result to the final key and replace keyb with result
final key: 12345k6jds7
keyb: k6jds7
You shift keyb 5 bits right and encrypt both keys, load result into keya and
add result to end of final key
keya: 98kio
keyb: ty76f
final key: 12345k6jds798kio
all done, since final key length = message lenght.

-p.s. These arnt real examples, I just used them to get the point across

[Hiroshe]

Just for the fun of it (remember this is not a serious algorithm, and should not be considered secure... atleast yet:) ) lets see if anyone can crack this. You may not use brute force, and you have to show me how you did it. I wana see how its done so maybe I can fix it. This is all using verison 1 of the encrpytion and all using the same key.

Document 1:
plaintext:  10101010 10101010 11001100 11001100
cyphertext: 10010100 10010000 00100010 11011100
Document 2:
plaintext:  11100011 01110111 11011011 00100100
cyphertext: 11011011 01000111 11010011 11010011
encrypted document:
cyphertext: 11100100 01101000 00100010 00110011

Decrypt the cyphertext, simple.

[Hiroshe]

I'm starting to see to many consistancies between the cyphertext and plain text in verison 1. It should be (theoreticly) fixed in version 2, but it still may cause a threat. If I put a xnor before the subtraction, it should make the plaintext "random?" enough for the the next stage. I know layering normaly dosn't add protection, but this time it seems its working.

data: 01100110 01110111 10011001
key:  11011011 00110011 11011100
---------------------------------
xnor: 01000010 10111011 10111010

xnor: 01000010 10111011 10111010
key:  11011011 00110011 11011100
---------------------------------
sub:  10011001 10001000 00100010

sub:  10011001 10001000 00100010
key:  11011011 00110011 11011100
---------------------------------
xor:  01000010 01000100 00000001

Result:
data:  01100110 01110111 10011001
key:   11011011 00110011 11011100
---------------------------------------------------
crypt: 01000010 01000100 00000001

It's still not secure, buts its not bad.

[thoughtcoder]

I should have been a little bit more clear. Can version 1 be cracked without a key (The answer is probably yes) assuming that the information & key is random.

What? If the information is random? You mean the plaintext? You can't crack a file without a key if the original file was random numbers, assuming the algorithm's output is the same length as the input. Only if it's something nonrandom, such as English text.

Can the version 1 key be found if you have a cypher/plaintext.

No, because not all parts of the key affect the output. (Edit: i misread your algorithm slightly in that I thought subtraction was going the other way. That should only slightly affect things.)

The idea of version 2 was to make pairs of bytes relitive to eachother. Heres an example of what I mean: If you have a small key, say "ab" and a plain text "cdce" and it cyphers into "ghgi" on version 1, but on version 2 it cyphers into "ghqj" becouse you are not doing a byte by byte cypher. (I.e. the byte beside the byte you encrypt will change both bytes.) Is my methed of doing this (subtracting in pairs) a good (simple) way to do this? If you make the bytes subtract in pairs of 4 or 8, will it provide better protection?

That only makes a nominal difference. With plain xor, there's only one possible output for any given (byte, index modulo keylength) value in the plaintext. With your algorithm, there are only two possible outputs. Thus the same technique used to find the keylength with plain xor can be used for your version 2 algorithm.

Sorry about my messy algorithm on version 3, ill make a better example.

You get a key from the user, and the lenght of the message.
key: 12345
length: 15
You then make two key variables with the key value.
keya: 12345
keyb: 12345
You add the value to the first part of the "final key"
final key: 12345
You shift keya 5 BITS left, lets say
kaya: h2g4n
kayb: 12345
you encrypt both keys, add the result to the final key and replace keyb with result
final key: 12345k6jds7
keyb: k6jds7
You shift keyb 5 bits right and encrypt both keys, load result into keya and
add result to end of final key
keya: 98kio
keyb: ty76f
final key: 12345k6jds798kio
all done, since final key length = message lenght.

-p.s. These arnt real examples, I just used them to get the point across

You're going to have to explain what the phrase "encrypt both keys" means. Having a real example would be more helpful.

Just for the fun of it (remember this is not a serious algorithm, and should not be considered secure... atleast yet ) lets see if anyone can crack this.

If you're going to invite people to crack something, you need to have a document significantly longer than four bytes. You can't generally decrypt four byte documents because you usually don't have enough information to get the key. In this case though you've given us the plaintext and ciphertext so getting the key is easy.

Edit: I thought there was something wrong with your examples but I was doing the subtraction the wrong way. One moment please...

[thoughtcoder]

Your second byte in document 1 seems impossible.

The plaintext byte is 10101010 and the ciphertext byte is 10010000.

There should be some k such that (k - 0xAA) XOR k = 0x90, right?

[thoughtcoder]

It's still not secure, buts its not bad.

It's not really any more secure than just doing subtraction. Subtraction is an operation where you work bit by bit on inputs x and y and produce one output bit and one "borrowing" bit. You figure out the output and borrowing bit using a truth table with the next two input bits and the current borrowing bit.

Addition works the same way, only we call it a "carry" bit and the truth tables are different.

And so do your combinations of subtract+xor and xnor+subtract+xor. The only change is in the truth tables.

[Hiroshe]

Thanks, you answerd all my questions. The only thing I don't get is how you break regular xor encrpytion if you use a key twice. The only way I found is this. Just find the text "how long". I can't see how you would find the exact plaintext if there is a subtraction before it, but I'm sure there's a way around it by using some other statisticle methed.

[Hiroshe]

Sorry, the key length is the same length as the message (4 bytes). Guess I should said that. I double checked and made sure it was right.

[thoughtcoder]

Sorry, the key length is the same length as the message (4 bytes). Guess I should said that. I double checked and made sure it was right.

What? What does the fact that your key length is 4 bytes have to do with anything? Please post some code that implements your algorithm because your english explanations are not exactly clear.