Experimental Physics and
Industrial Control System

Tony Cox - (415)926-3105 <[email protected]> · Tue, 14 Feb 1995 16:11:02 PST

(for those not yet bored with descriptions of the nuances of PGP)

Alan writes:-

>What Tony is proposing is a good way of handling the problem as well, let's
>take a look at the mechanics of each approach:
>
>
> {excellent blow-by-blow account of how a distribution hits the streets,
>  comparing pgp `conventional' encryption with public key method}
> 
>
>    
>Summary:
>
>Effort of public-key encryption is greater at startup for both distributor
>and customer but new-key distribution is eliminated.  The hard part in either
>case is key management - in one case giving the correct parties the key, in
>the other accepting public keys from the correct parties.  The difficulty of
>doing these are essentially equivalent.  Even though public keys can be
>emailed or posted without loss of security the verification process still 
>requires the same kind of secure channel and confidence that passing the
>private keys requires.

In principle, you are correct. But in practice, sharing the `conventional'
key is likely to be difficult logistically. This is, after all, why public key
cryptographic systems have become popular. In the conventional regime, someone
(lets say Bob - Hi Bob!) will encrypt the distribution with a pass phrase,
such as "I like EPICS". He'll then call everyone on the phone & tell them what
the new phrase is. Some will write this down as "I Like EPICS" or "IlikeEPICS"
or somesuch, neither of which will work when they finally get around to
downline loading the kit three weeks later when Bob is in bed. Eventually, the
decryption phrase will be e-mailed, probably even finding its way onto some
disk file so that users don't have to search around for some stupid scrap of
paper whenever the new release turns up. Now if a hacker grabs this file, or
intercepts the e-mail, all the source code is available.

Further, you have to (potentially) go through this process each time someone
leaves the EPICS collaboration, or if the pass phrase gets to someone who
hasn't signed the agreement. 

Contrast this with the public key approach. You e-mail Bob your public key,
and he calls you up on the phone to verify the key fingerprint (a list of
hex numbers which PGP can derive from your public key). Done once, and never
needs to be done again. Decrypting is simple, you only need to remember your
_own_ pass phrase to unlock your private key. Nothing for a hacker to grab; no
temptation to place anything compromising in either an e-mail or a local file.
New members of the collaboration can simply be asked to provide their PGP
key fingerprint on the collaborators agreement letter. People leaving the
collaboration can no longer decrypt the distributions, and others need make
no changes to continue being able to decrypt new distributions.

>I like Tony's public-key solution but it appears to be somewhat more work.

I don't think we are talking about much work here in either case. An extra five
minutes to generate your public key and e-mail it to Bob doesn't really add up
to much. And Bob doesn't get woken in the middle of the night by Australians
frantic for the pass phrase (nor do other active collaborators get bugged by
people for the phrase, when they may not have any legal right to it).

>The private key system minimizes the distributor's effort for each new 
>customer.
>
>The final choice should be by the distributor.

I think the (small) added effort to get the distribution right will pay off
later in less hassle for everyone. The private key system would quickly
degenerate into e-mail distribution of decryption keys. The decryption pass
phrase would become an open secret. Tate would find out that a competitor had
somehow managed to get the code, sue DOE for breach of contract, and put out
a contract on _you_ for even suggesting this! Hallucinogenic mushrooms would
sprout on the freeways. Global warming would get out of hand and we'd all end
up dead.

Not a pretty picture, is it?

Tony

--------------------------------------------------------------------------------
Dr Anthony D Cox
Computer Systems Specialist
Stanford Synchrotron Radiation Laboratory
Stanford Linear Accelerator Center
MS 69, Box 4349
Stanford CA 94305
[email protected]
--------------------------------------------------------------------------------

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System