[1996] in cryptography@c2.net mail archive
Re: secret history of the development of PK crypto
daemon@ATHENA.MIT.EDU (Phil Karn)
Wed Dec 24 00:56:23 1997
Date: Tue, 23 Dec 1997 20:47:08 -0800 (PST)
From: Phil Karn <karn@qualcomm.com>
To: smb@research.att.com
CC: cryptography@c2.net, mab@crypto.com, karn@qualcomm.com
In-reply-to: <199712171913.OAA12218@postal.research.att.com> (message from
Steven Bellovin on Wed, 17 Dec 1997 14:13:34 -0500)
>He spoke of National Security Action Memorandum 160 (from June 6, 1962),
>entitled "Permissive Links for Nuclear Weapons in NATO". The claim was
>that this memo -- signed by President Kennedy and endorsing a memo from
>his science advisor, Jerome Weisner -- was the basis for the invention
>of public key cryptography by NSA. Simmons nodded in vigorous agreement.
I've long had an interest in the principles of nuclear weapons. I
think it was the Progressive case in Wisconsin circa 1980 that got me
started. This was the magazine that had attempted to publish a
description of the principles of thermonuclear weapons from educated
guesses and public, unclassified information. Yet it attracted an
unusual level of attention from the Administration and an
(unprecedented?) prior restraint order banning publication.
Some time later I read about "permissive action links" (PALs). Based
on my understanding of how nuclear weapons operate, I began to think
about ways such things might be designed with cryptography as a
component.
Obviously, any mechanism designed to prevent the unauthorized use of a
nuclear weapon should resist attempts to defeat it. This is hard. If
the PAL consists merely of a combination switch in the firing line to
the detonators, anyone with modest technical skills could simply
hotwire it without attacking the switch itself. So something more
clever is needed.
Modern nuclear weapons (i.e., just about everything but the crude and
inefficient weapons developed during WWII) use a bare minimum of
fissile material. This is not only to conserve expensive Pu-239 and
U-235, but also to make the weapon safer to handle. Chuck Hansen's
book "US Nuclear Weapons" talks about the urgent post-WWII development
of "single point safe" weapons that would not undergo a nuclear
explosion if the conventional explosives were to detonate
accidentally, such as in a plane crash.
The gun-type "Little Boy" bomb used at Hiroshima is a good example of
a single-point UNsafe design. Once it was assembled, detonation of the
conventional explosive charge necessarily resulted in a nuclear
explosion. Even in wartime the risk of this happening at takeoff was
considered unacceptable, so the final assembly of the bomb was done on
the way to Japan.
Implosion-type bombs like the "Fat Man" dropped on Nagasaki are trickier
beasts. Multiple detonators have to be fired simultaneously to generate
the inward-moving shock wave that compresses the plutonium. Until it was
tested at Alamagordo NM, nobody knew if it would work. (Little Boy was
never tested -- it *had* to work, and it did.)
And modern thermonuclear weapons are even trickier still. Air gaps are
left between the conventional explosives and the fissile material,
allowing the shock wave from the former to "gather steam" before it
rams into the latter. Less fissile material is needed, because it is
used much more efficiently. An external neutron generator has to be
fired at just the right moment during the compression to start the
chain reaction. After fission starts, a deuterium-tritium mixture has
to be injected into it at just the right moment to "boost" it. And so
on. Precise timing of many interrelated events is essential.
Precise timing -- that's the key to my idea for a highly effective
PAL. First, design the weapon to make the firing sequence as
inherently complex and critical as possible. Vary the chemical
composition and detonation velocities of the various pieces of high
explosive so they have to be detonated non-simultaneously. Then store
all of the required timing data in encrypted form in the weapon's
memory. Better yet, encrypt *everything* (program and data) except for
a small bootstrap that accepts an external key and decrypts everything
for firing. Include this decryption key in the "nuclear weapons
release" message from the "National Command Authority" (I've always
loved that military terminology!)
Now if the weapon falls into the hands of a rogue commander or a
terrorist, he can't simply hotwire a switch. If he can't break the
encryption, he has to figure out for himself the correct timing of
each event that has to happen in sequence for a nuclear explosion to
occur. That's hard without significant technical help, even if he has
time and extra weapons to spare for, uh, a destructive testing
program.
I'm not sure how public key cryptography is especially helpful here,
as conventional encryption would work just fine.
Phil
