EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Making releases
From: Tony Cox - (415)926-3105 <[email protected]>
Date: Tue, 14 Feb 1995 10:20:04 PST
Alan K Biocca writes:-

>> From [email protected]  Tue Feb 14 01:15:15 1995
>> 
>> At the consortium meeting I suggested distribution via CDs.  This was 
>> considered too expensive.  In the light of the new concerns about 
>> security,  is this cost now overshadowed by the secure method of 
>> distribution that it offers?
>
>Perhaps more important than cost is timeliness - the distribution needs to 
>be tweaked too often to produce cdroms.  Who would want to wait for the
>'final' tweak, and then wait another N weeks for production and transportation..
>We normally get started with an early version and then incorporate the final
>later.  This would make for many cdrom versions.  Cdrom is excellent for
>infrequent releases of stable products to large audiences.  Our audience is
>small - production costs are high until a thousand or more
>are molded in a run...

I agree. I think CDrom distribution and the EPICS consortium (at its present
size & development) is a bad match.

>
>I think we should combine suggestions and provide a three-pronged approach:
>
>1) Use an ftp site with an account/password (this minimizes the number of
>   copies of the encrypted tarfiles floating about) AND

Why not provide the encrypted tar files via anonymous FTP? They are useless
to anyone without the key. Using conventional account/password security is
vulnerable to anyone with a sniffer anywhere between the distribution site and
the person trying to download it, so you might just as well set it up
anonymously. Or get everyone to Kerberize their FTP's...

>
>2) Encrypt with PGP -c (normal private key encryption), handling keys
>   by off-net channels to a minimum set of individuals who have signed
>   non-disclosure agreements on the keys and source.

PGP has a more secure method for doing what we want. You encrypt the file for
multiple users like this:-

	pgp -e R3.12.0.Tar Bob Chip Tony Alan Janet Uncle-Tom-Cobbly ...

The resulting encrypted file can only be decoded by the intended recipients.
Further, there is no need for any individual to be sent the decryption key. The
people who have signed the disclosure agreement just send the distributer their
public key. The `cost' for doing this is just 284 bytes per intended recipient
(in a previous post, I estimated 1000 bytes, but went away and checked to get
the number above), which is nothing compared to the 1.7Mbyte size of the base
distribution. What advantage is there using private key encryption, when this
is just the sort of application public key encryption is designed for?

>   Remember that the need to keep the key secure is exactly the same as
>   keeping the source distribution secure.  If it is relatively difficult
>   to get the encrypted distribution the key alone is not useful.

I think the assumption we should work under is that getting the encrypted
distribution is easy, so that key security is paramount! Isn't the idea here to
take the load off folks like Janet and Bob? What better way than for them to
encrypt the distribution & then stick it somewhere where everyone can get it.
No password to be changed, no necessity for security monitoring. When someone
joins the collaboration they just add their public key to the encryption list.
Rebuilding the encrypted distribution from the zipped tar file takes roughly
52+1.5n seconds (on my 30specmark VAX), where n is the number of intended
recipients. If someone leaves (hey, it could happen), they just remove the
corresponding public key & rerun the encryption script. Under your scheme, we'd
have to change the private key, re-encrypt, & then have to tell everyone that
the key has been changed. We'd also have to do that if the encryption
passphrase was disclosed accidentally, and probably periodically too! Far more
hassle.

The public key system lends itself to secure key management. The private
decryption key never needs to leave the machine on which it is stored. Even if
it is `grabbed', then it is useless without a private passphrase. If EPICS is
run on the same machine as the PGP private key database resides, then the key
is at least as secure as the source code we are trying to protect.

>    
>3) For those sites who don't or can't handle the encryption, put an
>   exebyte in the mail, or setup a special account and password and
>   then break it down as soon as they have downloaded.  This is still
>   weak since snooping the download is not difficult.
   
The only possible problem I can see is if ever have collaborators physically in
France. PGP is available, and legal, everywhere else as far as I know. Anyone
who can read this mail message can get a copy of PGP & then get up and running
within a few hours. There might be some pathological cases, I guess, but the
likelyhood of someone snooping a one-off download seems rather remote to me.
PGP will also automagically generate and decode 'ascii armoured' files which
can be sent via e-mail, for those without full Internet connectivity.


Tony Cox

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


Navigate by Date:
Prev: Re: Making releases Alan K Biocca
Next: Re: Making releases Jeff Hill
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Making releases Alan K Biocca
Next: Re: Making releases Jeff Hill
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·