[Cryptography] Hypothetical WWII cipher machine.

John Denker jsd at av8n.com
Sat Jul 18 12:39:40 EDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/17/2015 10:56 PM, Ray Dillinger wrote:
[....]
> He asked me for a detailed design for something that (A) could
> realistically have been built around WWII, (B) is not a rotor
> machine, (C) is very much more secure than Enigma, (D) that he
> could do a cool, interesting, understandable illustration of,
> (E) whose basic operation could be explained in one page or
> less, and (F) would not make real cryptographers laugh if they
> read his book.

Do you want good fiction, or good cryptography?  The
two are not entirely aligned.  
  a) For the story to work, most authors would want 
   the MacGuffin to be revolutionary and weird.
  b) For good practical cryptography, you probably want
   a machine that is an incremental improvement over
   the existing rotor machines.

If I were writing the story, I would defy the first
assumption and lampshade it:  The most remarkable
thing about my Mark-II Plot Device is that there is
nothing very remarkable about it.  It's a bundle of
relatively prosaic refinements that work well together.

> The diagram and one-page explanation are at
> 
> http://www.sonic.net/~bear/DiabolusCipherMachine.png
> 
> My only objections to it are practicality, not security; key
> setup would be a big pain in the butt, and during the
> process small removable parts could become lost making the
> machine useless.

Practicality is relevant here.  Cryptography exists 
at the intersection of esoteric mathematics and 
down-to-earth engineering.  The mechanical details
of the proposed Plot Device are unexplained, and 
seem implausible.  Unless you are going to send 
Ernő Rubik back in time to design the thing, it 
seems unlikely that the mechanics would operate
reliably.

> One of the problems with Enigma, and most rotor machines, is
> that too much of their state is static.  While their setup can
> have a lot of crucial bits, most of them are things that don't
> change during encryption/decryption

Slowly-changing state is "one" of the problems, 
but nowhere near the worst of the problems.

> [....] make
> the machines very prone to related-key attacks (which was how
> Bletchley Park worked). 

Yes, related-key attacks are a Big Deal.  Reference: 
excellent post by Ray Dillinger on 01/13/2015 02:28 PM.

> In fact the only thing that changes
> during encryption is the rotor positions, and those only
> describe a small fraction of the total state.

I don't see that as the essence of the problem.  The
Plot Device has a tremendously long cycle time ... 
but cycle time isn't the problem that most needed 
solving.  If the messages aren't hugely long, a 
modest cycle time suffices.  Conversely, it doesn't
matter how long the cycle time is, if the IVs span
only a small part of the state-space.  A longer and 
more secure IV is much closer to the heart of the 
matter.  That's a major contribution to the size of 
the search space the cryptanalyst must deal with.

To be specific:  Here's my Mark-II Plot Device:  Let's
drop requirement (B).  It's still a rotor machine, 
just a much-improved rotor machine.  My objectives are:
 *) The machine is mechanically reliable.
 *) The machine is electrically reliable.
 *) The machine is readily manufacturable using
  contemporary technology.
 *) The operating procedures don't place undue burdens
  on the ordinary code clerk.
 *) The hardware and procedures are cryptologically sound.

Description:

  1) Use 6 rotors straight-through (as in the M-209).
   That's better than using 3 rotors and a reflector.
   For starters, it gives a larger key-space.  Also it
   gets rid of the reciprocity bug.  If you want to get
   fancy, use 8 rotors.
  2) Choose those rotors from a set of 20. That's much
   better than choosing 3 from a set of 5, or even 4 
   from a set of 8.
  3) Make frequent changes to the Ringstellungen.
  4) Have a more sophisticated way of deciding which
   wheels advance (again, as in the M-209).  In my 
   Mark-II Plot Device, the wheels are advanced by
   solenoids (not by a motor).  Steppers of this
   kind were well-developed technology at the time,
   used in e.g. telephone switchgear.  Advancement
   is controlled by a some wheels in the "back 
   stage" area (taking the place of the drum+lugs 
   of the M-209).  Advancement depends in part on
   the plaintext and ciphertext, so there is an
   element of cipher chaining.  Each wheel has 
   roughly a 50% chance of advancement per character.
  5) Implement the permutation circuits (i.e. the
   inner wheels) using printed circuit boards.
   This was well-developed technology at the time.
   Millions of PCBs were made for e.g. proximity 
   fuses for anti-aircraft shells.  This means the
   wheels are cheap, lightweight, thin, strong, and
   reliable. This makes it feasible to ship 20 or
   more inner wheels with each machine.  The PCBs
   snap into the rings.
  6) Provide a set of dice, and require operators
   on pain of death to use the dice to select the
   message indicator (which nowadays would be called
   the initialization vector) ... and also the nulls.
  7) At the beginning of each message, and the clerk
   MUST insert a random number of random null words.
   Among other things, this means that no two cipher
   texts have the same length, even if a message
   has to be re-sent.
  8) There is a strict limit on the size of each message.
   If the payload is longer, break it into multiple
   messages, each with its own IV.  Also note that
   shorter messages are better in case retransmission
   becomes necessary.
  9) When generating the IV, whenever one character
   is needed, use the dice to generate a /pair/ of
   characters.  The IV as transmitted contains the
   pairs (duly encrypted), but when the IV is used
   for initializing the machine, each pair is collapsed
   to a single character using a lookup table.  Here
   is what the lookup table might look like for a 
   five-letter alphabet;  you can readily generalize
   it to the full alphabet:
   
           A  B  C  D  E
       A:  e  b  b  d  d
       B:  a  d  e  c  e
       C:  a  a  d  c  a
       D:  b  c  c  d  e
       E:  c  a  b  b  e

   That is, the bigraph (row,column) = (A, E) maps to
   the single character "d" in the upper-right corner
   of the table.  This makes it very much harder for
   the cryptanalyst to recognize related keys.  (This
   is an elaboration of the way the Naval enigma IVs 
   were handled.)
 10) The IV is encrypted /once/ using the key of the 
   day.  Then for redundancy, the encrypted version is
   transmitted twice.  The *exact same* ciphertext is 
   transmitted twice.  Let's be clear: the IV is not 
   encrypted twice;  it is encrypted only once and 
   transmitted twice.  
     (Otherwise the first encryption would serve as
      depth for cracking the second.)
 11) Test messages MUST consist solely of nulls;  not
  German proverbs;  not dirty jokes;  not 200 copies
  of the letter "L".  Validity is ensured by re-using
  the first null as the last;  due to chaining, this
  won't come through correctly unless all the rest
  is correct.

======================

Although the Allies could afford to build Bletchley Park,
they could not afford to build a million Bletchley Parks,
or even a thousand.

Expanding the key space by a factor of a million, and
hardening the IVs by even more than that, would make
the rotor machine secure for the duration of the war,
and for several years more than that.

=====================

This becomes a spy thriller as follows:  A couple of
Abwehr cryptanalysts are given a captured M-209 and
discover that it is (just barely) breakable.  They
put 2 and 2 together and figure that the Enigma must
be far more breakable.  They come up with a proposal
for a much stronger machine.

The Abwehr is thoroughly penetrated by people who
hate Hitler.  They want to suppress the Plot Device
proposal.  They can't just kill the analysts, because
that would just attract attention.  They have to
discredit them first........

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIVAwUBVaqBS/O9SFghczXtAQIedxAAkPlylpf3YGBMTmQmwmgpWigTuJ2V5DG8
L9isxmNxiON2vD5XQ4mbwB2pAWQP77Osz7jiHm2YwDbz+wXlEmTwZb8v4r19BONP
1RR/ACS/QN3rJoBf3cD1WMqUmjoML3PRQBCvtyw5p4x4akRQWtTnOQhrv2aFWQxZ
oVtaPMKlCapjrdaNctyCVSlKywuhGiVb12AV0C6YwOAODdV1iIhXnLKyV+Dgfvkh
VdcWts4LdNdZcjaClY3zSy3Ol8DpPRSXwrsqa/85BeRJtmwgDRxFaOOS5omwWJDY
mU82InLPtDaZQRK1iY7/1KwLD5ip7GAFre+w8f+Xco6va4Yyzw79J/Z+3SH/q9D/
Sdw8vfvQ4xmDuMinBkpZiNq+e9edsaaHJPYiUbssiCIWAFtM2uB9VSqSy339whzF
Dbj0o7ffXvHizs/RRllVOLv4Yw/rr1Du2vl2yWDNenPnVzdeTMvZ67s+w9gpxeh9
irp7LnB+TmOEgmTTnKvM1gqvaoyEN8S4FvlHgDsu/Q7GTofbwQJactOH1tSsixjv
Tp2cEA0cvBHQAYwxBpwGQJHJ6kVpb5Z/NF+irozxWa017Do12p+WAAObJV0AlOlR
H2O+0Thysmit+/0WPDmepShtkYgOTQYSi8+5RYa2HygQqgD5LyNUebozRfsGrEnq
/Dcr65nLPmo=
=RqQA
-----END PGP SIGNATURE-----


More information about the cryptography mailing list