[Cryptography] Imitation Game: Can Enigma/Tunney be Fixed?
jsd at av8n.com
Fri Jan 9 05:56:13 EST 2015
-----BEGIN PGP SIGNED MESSAGE-----
On 01/08/2015 11:18 PM, Ray Dillinger wrote:
> The Naval Enigma which had a papertape reader/writer attached
> could have been used to re-encrypt its own output, which would
> have eliminated the cant-map-to-itself problem and placed it
> completely beyond analysis with WWII methods
That's an excellent suggestion. Anything that gets
rid of the can't-map-to-itself bug is a huuuuge win.
The fact that it doubles the size of the IV and doubles
the number of rounds makes it even better.
IMHO this provides a clear answer to the question that
started this thread: Using the technology of the time,
yes, one could encrypt in a way that was not breakable
at the time.
Actually, superencrypting Enigma with "almost" anything
would have been a huge win. The stecker board, as
implemented, was one of the few things that /didn't/
solve the problem. A manual Playfair cipher would
have been better.
People blame the reflector, but IMHO would be better
to blame the idea of having encrypt mode be identical
to decrypt mode. The reflector was a consequence of
this bad idea, and the excessive symmetry of the
steckering was another consequence. The steckering
affected the input and output in the same way, so
it was still impossible for any letter to map to itself.
Anything that affected input during encryption and
output during decryption would have been better.
For example, the Fialka had a huge Frankenswitch to
select encode mode versus decode mode. This increased
the complexity, but solved the problem of excessive
> but it would
> have complicated the job of the cipher clerk and therefore
> made mistakes more likely as well, so that might not be a
> good idea in practice.
Well, let's see if we can alleviate that problem.
Here's a hypothesis to consider: With only a very
slight increase in complexity, construct an Enigma
with /two/ paper tape punches and /two/ readers.
During pass 1.0, the machine punches a copy of the
plaintext /and/ the intermediate codetext.
During pass 1.1, the two tapes are moved to the two
readers. The machine decrypts the intermediate codetext
and compares it against the plaintext. This catches
virtually all machine errors, along with a wide class
of operator errors (such as mis-setting the message
Before pass 2.0, the message indicators are changed.
During pass 2.0, the machine reads the intermediate
codetext, encrypts it, and punches out the final codetext.
During pass 2.1, the final codetext is decoded and
verified against the intermediate codetext.
Now the final codetext is ready to be transmitted.
Note: The three different tapes use different colors
of paper, to help keep them separate. You don't want
to accidentally transmit the plaintext. Possible
refinement: one could imagine making them physically
incompatible, e.g. different drive-sprocket holes.
This doesn't even add all that much to the workload,
since the added steps are few in number and are highly
automated. The added steps are well worth it in terms
of reliability and cryptologic strength.
I wouldn't want to carry out this procedure in a muddy
foxhole, but on a naval vessel or in a divisional HQ
caravan it shouldn't be a problem.
Obviously I haven't tried this, so it is just a hypothesis
at this point, but it seems worth a try.
At no time during the war was there any shortage of
It is straightforward to generalize to N rounds,
using no additional hardware, using time proportional
to N (or better), and tape proportional to N+1.
Even better than chaining N machines all alike is
chaining N machines all different.
As a separate matter: The message indicator was
sent using the key of the day. It was sent twice,
which improved reliability ... but created a weakness.
To alleviate the weakness, send the second copy using
a different key! Have two separate keys of the day.
The added workload is infinitesimal.
Also, as previously mentioned, roll the dice and choose
a /random/ steckering, which becomes part of the message
indicator. This is incomparably stronger than leaving
the steckering constant for an entire day and constant
across all stations.
Of course this implies adding stecker boards to Navy
and Abwehr machines (not just Army machines).
Roll the dice and send a bunch of random null letters
at the head of the message. Keep rolling until you
get two letters the same, so it randomizes the length
of the message as well. Ditto at the end. Sprinkle
random null codewords throughout the message. Take
null codewords from a codebook, or make up hamXster
your own pupXpy nonsense words kitXten as you go along.
Bottom line: There was a lot they could have done
with 1930s technology. Minor tweaks to the procedures
would have made a huge difference.
On 01/07/2015 01:23 PM, Ray Dillinger wrote:
> Does every large-scale military organization make stupid mistakes
> subordinating security to petty officiousness, redundant procedure,
> personal ego, and just plain laziness?
Ditto for non-military organizations.
Actually it is even worse than that. There are structural
reasons why code-breaking is rewarded more than code-making.
As we have discussed previously, the guy who benefits from
cryptanalysis /knows/ how much he is benefiting. They guy
who benefits from having strong crypto is never quite sure
how much good it is doing.
Note that the Manning, Snowden, and Sony incidents are
remarkable for being not nearly as severe as they could
have been, because the leakage was well publicized. This
is very different from the Enigma/ULTRA situation, where
the break was exploited for years without the broken side
finding out about it.
I mention this because a manifest break is one of the few
things that will get people to stop sucking their thumbs
and start paying for strong security.
> Is this level of
> operational failure something that people need to design for
> if building systems for military clients?
Ditto for non-military clients.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
-----END PGP SIGNATURE-----
More information about the cryptography