Is my Enigma inspired cipher any good?

Question

I am working is a project that would implement a cipher that would output ciphertext that would be easy to transmit through morse code, just like they did in the days of Enigma.

Use of AES or the likes would of course work, but the downside is that since AES can encrypt 256 different values for each character, the resulting ciphertext would have to be encoded to limited character set to satisfy above requirement, eg to hex using only characters 0-9 and A-F. This will result in ciphertext that is at least twice as long as the original plaintext, so it be harder to transmit.

This got me working on a Enigma style computerized rotor based cipher, with some steroids. This is how I envisioned it would work:

• It would have a larger character set of 47 characters ([A-Z][0-9][.+-?!&@:=] (I chose this because 47 is a prime number)
• It would have 47 rotors, each with different mapping. Each rotor would have an identifier from the above 47 available characters
• for encryption/decryption, 10 rotors would be chosen from 47, but a rotor can be chosen multiple times
• Each rotor would step 1-4 times between each encryption, this would be determined by the rotor ID and its initial position.
• No deflector, for decryption the cipher would simply be run through the rotors in opposite order. A character CAN map to itself so a big flaw in original Enigma is solved.

So the keyspace would be formed from selecting 10 rotors in random from 47, and setting an initial start position of each into any of the 47 possible positions. So Keyspace would be 47^20 = 2.77E33 or roughly 111 bits. So I suppose brute force attack is infeasible. we would use the key so, that first 10 digits are the chosen rotors, and remaining 10 digits are the initial positions of the rotors (IV).

The actual encryption would work like this. First we generate a random 10 character initialization vector (IV), and encrypt that with the above message key. Then we use the resulting ciphertext (10 characters long) as the new IV for the next 10 characters to encrypt and so on until we reach the end of the message. To decipher, we do this in reverse. We know that first 10 digits are the IV for the next 10 digits and so on.

Example, Plaintext is "HELLO+WORLD+OF+ENIGMA", Message key is "01234567899876543210" (for simplicitys sake, I did not actually run this through the algorythm)

• Generate random IV, eg "ABCDEFGHIJ"
• Encrypt above with messagekey "01234567899876543210", this results in "KLMNOPQRST", add that to ciphertext
• Encrypt first 10 characters of plaintext ("HELLO+WORL") with key "0123456789KLMNOPQRST", this results in "K?+L&KMWI7", add that to cipher text which is now KLMNOPQRSTK?+L&KMWI7
• Encrypt next 10 characters of Plaintext ("D+OF+ENIGM") with key "0123456789K?+L&KMWI7", this results in "8/HFP:=JGR", add that to cipher text which is now KLMNOPQRSTK?+L&KMWI78/HFP:=JGR
• Encrypt remaining 1 character ("A") with key "01234567898/HFP:=JGR" which results in A, so final ciphertext is KLMNOPQRSTK?+L&KMWI78/HFP:=JGRA

The result is something that would be easy to transmit in morse code, as well as easy to spell over voice radio etc. It only adds 10 characters to the length of the original message.

But how secure would that be ? I know brute force would not be an issue. But assuming the rotor mappings are known, how about more sophisticated forms of cryptoanalysis ? One obvious thing I can think of is that the attacker would know the length of plaintext (=length of ciphertext less 10), but is that really an issue.

Answer 1

But how secure would that be ?

Not very; there's an obvious known-plaintext-attack that recovers the key settings with effort equivalent to about $2^{28}$ encryptions; that'd be less than a minute on a single CPU core (perhaps much less, depending on the speed of the cipher implementation).

Two obvious observations:

• You count the initial positions of the rotors as 'key'; however you expose them in the ciphertext (and so the attacker would know them). The only thing initially unknown to the attacker is the rotor selections (and the initial settings used to generate the IV; the attacker doesn't care about that)

• There's an obvious meet-in-the-middle attack; with a known plaintext/ciphertext pair (with known IV settings), we can scan through all $47^5$ possible selections for the first five rotors, and encrypt the plaintext through the first half the cipher with those, coming up with $2^{47}$ possible intermediate values. Then, we can scan through all $57^5$ possible selections for the last five rotors, and decrypt the ciphertext through the last half of the cipher, coming up with $2^{47}$ possible intermediate values. Check the two lists for a common value - that'd be the rotor settings.

BTW: if you are really interested in this 'encryption with a reduced alphabet' problem (rather than just playing around with designing your own system), you might want to read up on Format Preserving Encryption...