Name: Anonymous 2019-03-01 20:08
The Chaocipher works like this[0]:
1. Generate a "ciphertext" (CT) alphabet
2. Generate a "plaintext" (PT) alphabet
3. Establish a "plaintext message" consisting of a series of letters
For each letter in your plaintext message:
1. Rotate the PT alphabet left X times so that the selected PT letter is the first letter of the PT alphabet
2. Rotate the CT alphabet left the same X times, too
3. Use the first letter of the CT alphabet as the CT letter that corresponds to the PT letter
4. Scramble the CT alphabet one predetermined way, and scramble the PT alphabet another predetermined way.
5. Repeat until no letters remain.
6. To decrypt, swap "PT" with "CT" for steps 1-3.
Now what I've noticed is that nearly every implementation uses the same alphabet scrambling techniques for step 4:
1. CT alphabet: 1, 3-14, 2, 15-26
2. PT alphabet: 2-3, 5-15, 4, 16-26, 1
so that scrambling the standard alphabet (ABC...XYZ) once provides these alphabets...
1. CT: A CDEFGHIJKLMN B OPQRSTUVWXYZ
2. PT: BC EFGHIJKLMNO D PQRSTUVWXYZ A
(for clarity, I add spaces to show where the alphabets were cut)
Some cryptographers have argued that the initial order of the plaintext alphabet has no value as a "key"[1] because, when a correct ciphertext alphabet is supplied to decrypt a message, the result, regardless of the plaintext alphabet used, can always be "corrected" via simple substitution. So, why not use the methods in which the alphabets are scrambled as an additional key?
Here I represent the two scrambling methods in standard "array slicing" notation...
1. CT scramble: [0:1] [2:14] [1:2] [14:25]
2. PT scramble: [1:3] [4:15] [3:4] [15:25] [0:1]
Now these can be translated into keys by taking a list of all numbers referenced, and replacing the numbers with their equivalent in an alphabet:
1. CT -> [0 1 2 14 1 2 14 25] -> [ ABCOBCOZ ]
2. PT -> [1 3 4 15 3 4 15 25 0 1] -> [ BDEPDEAPZAB ]
Instead of using a necessary ciphertext alphabet as the key, along with a basically unnecessary plaintext alphabet, instead use the necessary ciphertext alphabet along with 2 different shuffling techniques for CT and PT alphabets. Ruiz argues that the keyspace of Chaocipher with its two alphabets is not 176 bits of entropy `(log2(26!) * 2)` but 88 bits of entropy `(log2(26!))` due to isomorphism between all initial plaintext alphabets. It seems to me that acknowledging the possibility of multiple scrambling methods could increase the entropy of the keyspace, but I really know nothing about statistics.
Any crypto nerds have any thoughts on my proposed improvements to Chaocipher?
[0] https://rosettacode.org/wiki/Chaocipher Chaocipher - Rosetta Code
[1] https://prgomez.com/scrabble-cipher/ - The Scrabble cipher - PR Gomez
[A] https://www.dcode.fr/chao-cipher - Chaocipher Cipher - Decoder, Encoder, Solver, Translator
1. Generate a "ciphertext" (CT) alphabet
2. Generate a "plaintext" (PT) alphabet
3. Establish a "plaintext message" consisting of a series of letters
For each letter in your plaintext message:
1. Rotate the PT alphabet left X times so that the selected PT letter is the first letter of the PT alphabet
2. Rotate the CT alphabet left the same X times, too
3. Use the first letter of the CT alphabet as the CT letter that corresponds to the PT letter
4. Scramble the CT alphabet one predetermined way, and scramble the PT alphabet another predetermined way.
5. Repeat until no letters remain.
6. To decrypt, swap "PT" with "CT" for steps 1-3.
Now what I've noticed is that nearly every implementation uses the same alphabet scrambling techniques for step 4:
1. CT alphabet: 1, 3-14, 2, 15-26
2. PT alphabet: 2-3, 5-15, 4, 16-26, 1
so that scrambling the standard alphabet (ABC...XYZ) once provides these alphabets...
1. CT: A CDEFGHIJKLMN B OPQRSTUVWXYZ
2. PT: BC EFGHIJKLMNO D PQRSTUVWXYZ A
(for clarity, I add spaces to show where the alphabets were cut)
Some cryptographers have argued that the initial order of the plaintext alphabet has no value as a "key"[1] because, when a correct ciphertext alphabet is supplied to decrypt a message, the result, regardless of the plaintext alphabet used, can always be "corrected" via simple substitution. So, why not use the methods in which the alphabets are scrambled as an additional key?
Here I represent the two scrambling methods in standard "array slicing" notation...
1. CT scramble: [0:1] [2:14] [1:2] [14:25]
2. PT scramble: [1:3] [4:15] [3:4] [15:25] [0:1]
Now these can be translated into keys by taking a list of all numbers referenced, and replacing the numbers with their equivalent in an alphabet:
1. CT -> [0 1 2 14 1 2 14 25] -> [ ABCOBCOZ ]
2. PT -> [1 3 4 15 3 4 15 25 0 1] -> [ BDEPDEAPZAB ]
Instead of using a necessary ciphertext alphabet as the key, along with a basically unnecessary plaintext alphabet, instead use the necessary ciphertext alphabet along with 2 different shuffling techniques for CT and PT alphabets. Ruiz argues that the keyspace of Chaocipher with its two alphabets is not 176 bits of entropy `(log2(26!) * 2)` but 88 bits of entropy `(log2(26!))` due to isomorphism between all initial plaintext alphabets. It seems to me that acknowledging the possibility of multiple scrambling methods could increase the entropy of the keyspace, but I really know nothing about statistics.
Any crypto nerds have any thoughts on my proposed improvements to Chaocipher?
[0] https://rosettacode.org/wiki/Chaocipher Chaocipher - Rosetta Code
[1] https://prgomez.com/scrabble-cipher/ - The Scrabble cipher - PR Gomez
[A] https://www.dcode.fr/chao-cipher - Chaocipher Cipher - Decoder, Encoder, Solver, Translator