If I 'shuffle' the characters in a long text, is there some number of shuffles that will produce apparent randomness approaching a cryptographically secure random number generator? A chapter in a widely available novel online, then, would produce a key suitable for a stream cipher, Vernam cipher, etc., would it not? If not could someone help explain why?
$\begingroup$
$\endgroup$
4
-
$\begingroup$ If your text contains all 26 letters in the alphabet, what is the minimum number of ways of randomly permuting that text? $\endgroup$– AzarinakCommented Mar 1, 2016 at 19:34
-
$\begingroup$ Imagine a chapter in a novel as the 'long text' 15,000 chars. So the minimum number of ways of randomly permuting the text is 1, the maximum # of ways is 15,000! I think. Also this is for a stream cipher key, where the key must be as long as the plaintext. $\endgroup$– J Presper EckertCommented Mar 2, 2016 at 8:44
-
$\begingroup$ Permuting a long text gives enormous probability, but just using that permutation on its own will fail due to statistical analysis explained by chell. So shuffling the text, while probabilistically 'random', can still be broken $\endgroup$– AzarinakCommented Mar 2, 2016 at 18:11
-
$\begingroup$ Understood. I have to introduce noise into the key. Thank you. $\endgroup$– J Presper EckertCommented Mar 2, 2016 at 20:55
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
6
If by "shuffle", you mean permutation of the characters of your alphabet, then no. The reason is text in English (and any other language for that matter) contains quite a bit of redundancy. If you simply permute the letters, you can always do statistical analysis on the resulting text and figure out quite easily that the most commonly occurring letters are probably E, A, and T. Moreover, compositing permutations on top of permutations just results in another permutation, which means shuffling the letters more times is useless since you could have just used a different permutation to begin with.
Let's say you use a pretty long chapter of a novel, permute it, and use the result as your key. Let's assume, best case scenario, you're going to use it to encode a message as long as your key, like a crummy one time pad. Except the reason a one time pad is secure is because in generating the key, each letter is independent and identically distributed with probability 1/26, whereas your key was generated by a permutation of the distribution of regular english text which is not uniformly distributed.
This means some letters are going to occur more frequently than others such as (A, E, or T) XOR (permutation of A, E, or T). You can still do statistical analysis on this ciphertext, and figure out what permutation of letters correspond to the most frequent ones in a number of trials. Then you plug in those permutations into the key and recover the key by guessing the rest of the words in the key.
-
$\begingroup$ chell: thanks so much. yes, a permutation, a reordering of the my long chapter. Yes, the key will have ETAIONSHRDLU frequency distribution. So will the plaintext. But when each plaintext char's ascii value, for example, is added to, for example, the key char's ascii value, the letter frequency will be statistically much harder to discern. I make my cipher digits representing the encrypted plaintext char a string. I prepend and append meaningless, but a known number of, numeric digits. Make it all a csv file and it looks like more Big Data. Still weak? Or just not perfect? thanks very much. $\endgroup$ Commented Mar 2, 2016 at 8:40
-
$\begingroup$ chell: also, to further remove the English letter frequency distribution, I could do a bit shift or some other character by character manipulation on the key to make a 'E' an unrelated numerical value different from the next enciphered 'E' in the key from the long novel chapter. As long as my manipulation was reproducible and reversible by Alice, she could read my message. There seem to be enough different ways to disturb the key, switch the book or chapter for the key for the next message, and it approaches unbreakable. Or am I still missing something? Thanks. $\endgroup$ Commented Mar 2, 2016 at 8:50
-
$\begingroup$ "Make it all a csv file and it looks like more Big Data." You are confusing cryptography with steganography. What you are describing is OTP with the key and the message both in plain English, or some slight modification thereof. Intuitively, this is like taking a picture of a smiley face and XOR it to a picture of the words "SEND CASH" (see link below, top answer). A permutation of the key's alphabet is akin to permuting the colours of one of the pictures. crypto.stackexchange.com/questions/59/… $\endgroup$– user10437Commented Mar 2, 2016 at 17:05
-
$\begingroup$ @JPresperEckert: In your 1st comment above, you mentioned the case of adding key characters (similar in essence to addition mod 26, I suppose). The frequency distribution is of course changed, depending on the key stream. In general there will be some (more or less) improvements. (In the special case that the key stream is ideally random, the resulting stream will also be ideally random. But this fact is apparently not of practical relevance.) $\endgroup$ Commented Mar 2, 2016 at 17:29
-
$\begingroup$ chell, I was answering someone's question that day about hiding the resulting ciphertext. I now understand the requirement for a OTP to have a truly random key. I now have access to very long random strings of data. So now I should, theoretically, be able to produce an unbreakable cipher using OTP w/ TRNG data for key generation. Does that sound accurate? Thanks for your time. $\endgroup$ Commented Mar 2, 2016 at 21:55