[2001] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: secret history of the development of PK crypto

daemon@ATHENA.MIT.EDU (Rick Smith)
Wed Dec 24 13:20:37 1997

In-Reply-To: <199712240447.UAA29040@servo.qualcomm.com>
Date: Wed, 24 Dec 1997 11:35:28 -0600
To: Phil Karn <karn@qualcomm.com>, smb@research.att.com
From: Rick Smith <smith@securecomputing.com>
Cc: cryptography@c2.net, mab@crypto.com, karn@qualcomm.com

At 8:47 PM -0800 12/23/97, Phil Karn wrote:

>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 recall reading about this approach somewhere, probably the book "The
Logic of Accidental Nuclear War," published by the Brookings Institute
(sorry, I don't have it handy and forgot the author's name -- the day
before holidays, etc). The book describes features of both US and Soviet
release mechanisms.

The nice thing is that the key doesn't have to be stored in the device, and
without the key you can't operate the device -- all you have is fissile
material, some shaped charges, and a lot of random elecronics. Careless
handling is more likely to kill intruders with radiation than it is to
yield a big boom.

Steve Bellovin's point about using PK for non-repudiation is interesting.
One wonders if there's then a dictionary of public keys to cover a variety
of authorization authorities. Or perhaps that would be over-engineering.

Rick.
smith@securecomputing.com



home help back first fref pref prev next nref lref last post