Posted: Thu Aug 04, 2011 5:16 pm Post subject: My encryption ponderings
I was working on making a better version of hand encryption, and I came accross an interesting thing. If you use a zero-based index for the alphabetic numbers, it kinda makes things very odd.
a+a=a
b+a=b
c+a=c
it's very odd. On a related note, would anyone like to try to break my encryption? If someone would like to attempt it I will post the encryption method along with encrypted message, and we can see who can unencrypt it first. Note that this is encrypted with pen and paper, but yes, you may use all the computer tools you would like.
Sponsor Sponsor
Ultrahex
Posted: Thu Aug 04, 2011 6:16 pm Post subject: Re: My encryption ponderings
post-away...
mirhagk
Posted: Thu Aug 04, 2011 9:18 pm Post subject: RE:My encryption ponderings
Alright I have a very basic sentence and I am working on a bigger one now, otherwise it will be impossible to decrypt (to save me time I'm going to get a computer to encrypt, but the algorithm is easy enough to do without)
The algorithm is basically a branch off of the vegeniere cipher. I doubt it's very good, but it's better than that at least, since it covers it falls. Here's what it does:
Take your keyword: compsci
then use your keyword to encrypt itself (as in a simple adding the letters together). Now you have a 2nd keyword. Use the 2nd keyword to encrypt itself, you'll now have a 3rd one that's 4 times as long as the first. Keep doing this till the key is as long as the message. Now use the key to encrypt the message. The key (other than the first part) will have no english components, and no normal language patterns in it, and it does not need to be repeated, so it overcomes the weaknesses of vegeneiren cipher. (I know I'm spelling that wrong lol).
Do you guys have any obvious mistakes I missed lol?
Tony
Posted: Thu Aug 04, 2011 10:11 pm Post subject: RE:My encryption ponderings
If I understand this correctly, you are programmatically expanding a simple key into a running key. Should the full key be truly random, the key itself would be cryptographically secure (the distinction is that security is in the key and not the encryption method). But considering that all of the key's entropy comes from the original weak key, the running key is not truly random. I suspect that this theoretically breakable for long enough texts, especially if more information is know (e.g. key and text are derived from a known language).
Posted: Thu Aug 04, 2011 11:37 pm Post subject: RE:My encryption ponderings
First, a quick guess: your final key tends to contain exclusively these letters: ACEGIKMOQSUWY .
Let's assume that length ( key ) < length ( message ). This is sort of an implicit assumption in the algorithm as you wrote it anyway, so I don't think I'm overreaching here.
Based on your description, the following is my understanding:
key0 = original key = "KEY" (for example)
key1 = key0, "encrypted" by itself and concatenated = "UIWUIW"
key2 = key1, same procedure = "OQSOQSOQSOQS"
(etc)
Let's call the number of such steps "d". If the message is SHORTER than the key, then doublings will be 0, otherwise it will be 1 or more. In general, d will be given by:
code:
d = ceil ( log2 ( msg_length / key_length ) )
So the value of your full key at index i can be computed by:
code:
full_key [ i ] = 2 ^ d * original_key [ i % key_length ] (mod 26);
Since d > 0, we know that full_key [ i ] will be even. Thus, we know that the low bit of every byte in the plaintext is UNDISTURBED by applying the final key.
Even better, we know that there are only 13 possibilities for each entry in the final key (no matter what you put in your original key), because they are all congruent to 2 ^ d mod 26, which gives us only 13 non-negative possibilities: 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24: ACEGIKMOQSUWY .
This reduces your possibility space for the key from 26 ^ key_length to 13 ^ key_length. This means that the possibility space is only 1 / ( 2 ^ key_length ) the size it would be otherwise.
The rest of the attack follows pretty much the same pattern as the attacks on the Vigen?re cipher do, with the added bonuses that we have half as many Caesar ciphers to consider and that we can use that free low-bit to help in frequency analysis.
Finally, once the per-column Caeser ciphers have been cracked, you get both the plaintext and the original key, just as you do in the original Vigen?re cipher.
Tony
Posted: Fri Aug 05, 2011 12:17 am Post subject: RE:My encryption ponderings
This interpretation of the key generation is no different than the classic Vigenere's cipher, but using OQS instead of KEY (so probably non-english key, but that doesn't prevent any of the classic attacks (since variants of using numeric keys have also been shown to be breakable)).
My interpretation was that each block of the key_length was encrypted a different number of times, resulting in a running key like OQSUIWKEY (so, key2 + key1 + key0; etc).
Which seemingly fixes attacks that target repeating key blocks.
Posted: Fri Aug 05, 2011 12:36 am Post subject: RE:My encryption ponderings
If true, that gives you even more information to attack the algorithm with...I think. Maybe mirhagk could clarify?
mirhagk
Posted: Fri Aug 05, 2011 7:36 am Post subject: RE:My encryption ponderings
Tony got it mostly right, sorry for not clarifying. The key is encrypted with itself, and this new key is appended to the old one. For instance KEY becomes KEYUIW. Then this new key is treated the exact same, making another key of KEYUIWEMUOQS and so on and so forth. I do believe DemonWasp is still correct in that the final values of the key can only be one of those 13 values, so I'm thinking about improving it with this little trick. Instead of encrypting KEY with KEY you'd encrypt it with YEK, and same for each one that comes out. I believe it should give more variance, although I could be wrong.
The whole idea of it is to get a key with enough pseudorandomness that you would need a rediculous amount of text in order to decrypt it. It's already been shown that a truly random key as long as the text is indecipherable. (Assuming of course you don't have unlimited time) so a pseudorandom key should fare fairly well.
There is actually a similar concept to this, where you use the text appended to the key as part of the encryption. The problem with this is that the word THE is nearly guaranteed to be part of the key.
EDIT: This new way may make it less secure, as I see ALOT of triplets (KEY encrypted with YEK is III)
EDIT2: AHHH I REALLY CAN'T DECIDE. The 2nd way shows up less random, but it has more varance(if the letter be is used in the key, it can show up in the final key). The 1st way is restricted to those 13 characters, but looks pretty random (I know it's not, but it looks decent).
Sponsor Sponsor
mirhagk
Posted: Fri Aug 05, 2011 8:30 am Post subject: RE:My encryption ponderings
that's using the original (non-reversed key) algorithm.
DemonWasp
Posted: Fri Aug 05, 2011 11:22 am Post subject: Re: My encryption ponderings
My criticism (mostly) holds. Beyond the first key_length bytes then, the full key will include only multiples of two, and will therefore have only 13 possibilities. This weakness would disappear if you did something radical, like adding an extra character or removing one, just so the alphabet has an odd number of characters. For example, you could replace all instances of Z with S, or you could add an underscore to the alphabet.
The pattern of the number of "doubling" operations for the repetitions of the original key will be:
Obviously that's a fairly simple pattern. I'm too stupid / tired / lazy to write out the algorithm, but there's definitely an easy one (it's a fractal pattern, probably reproducible by an L-system, if it turns out to matter).
At this point, however, we've pretty much exhausted my ability to analyze encryption algorithms. I don't really have any training in the matter and as far as university-level math goes, I've mostly passed by accident.
mirhagk
Posted: Fri Aug 05, 2011 12:02 pm Post subject: RE:My encryption ponderings
so by adding a single character to the alphabet it would be more secure? In that case I can just have spaces be a character.
DemonWasp
Posted: Fri Aug 05, 2011 12:39 pm Post subject: RE:My encryption ponderings
I wouldn't recommend spaces, for two reasons. First, they're difficult to deal with in the output of the program, particularly in cases where the encrypted text is being parsed out of a message by something that separates tokens by white space.
Second, and more importantly, spaces show up extremely frequently in text of many languages; if you analyze any given text, you'll find that spaces are far more common than the letters 'e', 's', 't', etc. This makes frequency analysis much, much easier.
In fact, it might be best if the alphabet had a prime number of symbols, such as 29. You could add exclamation, full stop (period) and question mark, for example.
Out of curiosity, why are you working on modifying a known-breakable single-key algorithm, when we have public-key encryption (RSA) which nobody seem to think can be cracked in a reasonable period of time?
mirhagk
Posted: Fri Aug 05, 2011 2:08 pm Post subject: RE:My encryption ponderings
Well I am doing it because an encryption this simple can be done with a piece of paper and a pencil (and for making it quicker a table to look up what values turn into what). RSA requires a computer in order to be implemented, and so lacks the ability to encode hand written things.
Brightguy
Posted: Fri Aug 05, 2011 8:23 pm Post subject: Re: My encryption ponderings
The standard Vigenère-cracking method would work here, except it would take up to ~26 times longer because once the key length is determined you have to try 26 possibilities for each key position rather than directly seeing the proper shift amount in the frequency graph.
Incidentally, RSA is so remarkably simple that it can still be done by hand (though naturally it will be more computationally expensive than this as it requires multiplication).
DemonWasp
Posted: Fri Aug 05, 2011 10:05 pm Post subject: RE:My encryption ponderings
Fortunately, exponentiation modulo N (which is what RSA requires) is relatively simple to perform, even by hand.