[Cryptography] Imitation Game: Can Enigma/Tunney be Fixed?

Fri Jan 9 05:56:13 EST 2015

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 
symmetry.

> 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 
indicators).

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 
paper tape.

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? 

Yes.

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?

Yes.

Ditto for non-military clients.