[8518] in cryptography@c2.net mail archive
Re: Leo Marks
daemon@ATHENA.MIT.EDU (Steven M. Bellovin)
Tue Jan 30 23:30:20 2001
From: "Steven M. Bellovin" <smb@research.att.com>
To: "R. A. Hettinga" <rah@shipwright.com>
Cc: cryptography@c2.net
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Tue, 30 Jan 2001 21:58:43 -0500
Message-Id: <20010131025843.9A41035C42@smb.research.att.com>
The obituary has, at long last, prompted me to write a brief review of =
Marks' book "Between Silk and Cyanide". The capsule summary: read it, =
and try to understand what he's really teaching about cryptography, =
amidst all the amusing anecdotes and over-the-top writing.
The main lesson is about threat models. If asked, I dare say that most =
readers of this mailing list would say "of course keying material =
should be memorized if possible, and never written down". That seems =
obvious, especially for agents in enemy territory. After all, written =
keys are very incriminating. It's obvious, and was obvious to the SOE =
before Marks. It was also dead-wrong -- accent on the "dead".
The cipher that agents were taught was a complex transposition, keyed =
by a memorized phrase. The scheme had several fatal flaws. The first =
is the most obvious: a guess at the phrase was easily tested, and if a =
part of the key was recovered, it wasn't hard to guess at the rest, if =
the phrase was from well-known source (and it generally was). =
More subtly, doing the encryption was an error-prone process, =
especially if done under field conditions without the aid of graph =
paper. Per protocol, if London couldn't decrypt the message, the agent =
was told to re-encrypt and re-transmit. But that meant more air time =
-- a serious matter, since the Gestapo used direction-finding vans to =
track down the transmitters. Doing some simple "cryptanalysis" -- too =
strong a word -- on garbles permitted London to read virtually all of =
them -- but that was time-consuming, and really pointed to the =
underlying problem, of a too-complex cipher.
The duress code was another weak spot. If an agent was being compelled =
to send some message, he or she was supposed to add some signal to the =
message. But if the Gestapo ever arrested someone, they would torture =
*everything* out of that person -- the cipher key, the duress code, =
etc. And they had a stack of old messages to check against -- they =
made sure that the duress code stated by the agent wasn't present in =
the messages. The failure was not just the lack of perfect forward =
secrecy; it was the lack of perfect forward non-verifiability of the =
safe/duress indicators.
Marks' solution was counter-intuitive: give the agent a sheet of =
"worked-out keys", printed on silk. These were not one-time pad keys; =
rather, they were the numeric indicators for the transposition. This =
avoided the guessable phrases; more importantly, it eliminated the most =
trouble-prone part of the encipherment, the conversion of the key =
phrase to a numeric version. The authentication codes were a function =
of part of the key. Agents were instructed to destroy each "WOK" after =
use; this provided not just forward secrecy, but also stop the =
Gestapo from verifying any statements about the duress code. =
Why silk? Because it was easily concealed in coat linings and the =
like, and wouldn't be detected in a casual street-frisk. Sure, if the =
Gestapo was really suspicious, they'd find it. So what? This is the =
*Gestapo*; if they were really suspicious, it didn't matter much if you =
weren't guilty, because you'd be in no shape to appreciate their failure =
to find anything. We joke about rubber hose cryptanalysis; the SOE =
agents had to contend with the real thing. And real agents had enough =
other incriminating stuff lying around that unused keys didn't matter.
There's more, but the basic lesson is clear: understand the *real* =
threat model you face before you design any sort of security system. =
The SOE didn't, and that cost the life of many agents.
--Steve Bellovin, http://www.research.att.com/~smb
