[528] in linux-security and linux-alert archive
Re: Getting security tools into a mainstream distribution
daemon@ATHENA.MIT.EDU (owner-linux-security@tarsier.cv.nr)
Tue Dec 19 07:11:25 1995
From: owner-linux-security@tarsier.cv.nrao.edu
Date: Mon, 18 Dec 1995 15:26:02 -0600
To: R.E.Wolff@et.tudelft.nl
Cc: Dave Stagner <david_stagner@sys1.ic.ncs.com>,
Thomas.Koenig@ciw.uni-karlsruhe.de, linux-security@tarsier.cv.nrao.edu
R.E.Wolff@et.tudelft.nl wrote:
>
> >
> > I see one major problem with this... any encryption software based on
> > the RSA algorithm (most notably PGP) is subject to patent restrictions
> > in the US entirely separate from export restrictions. Free software
> > using RSA released in the US must legally be built using the RSAREF
> > library (used by the US version of PGP distributed by MIT), while
> > RSA-based software used overseas uses a clone of the RSAREF library (I
> > can't remember its name offhand). Meanwhile, the RSAREF library itself
> > is illegal to use outside the US (at least according to US law!)
>
> How about the following: if someone outside the US makes a version
> of the software that through installation of a shared library becomes
> cryptographically enabled. This part of the software needs to be
> based outside the US, as this type of software is ITAR regulated.
> (Yes: Just because you can plug in a Crypto unit, it itself becomes
> cryptography, and thus regulated).
>
> What could be implemented should be capable of simultaneously
> supporting several different "plug-and-play" modules that handle the
> cryptographic side of the stuff. This allows non-us-based sites to
> distribute a version that contains a non-RSA module, which can be
> augmented with the RSAREF unit inside the US, and the clone outside
> the USA.
I really like the idea of using shared libraries to handle crypto stuff
(let's make sure the system is immune from the linker bug first!).
Phil Zimmerman is already working on a very useful addition to our
secure software systems. I talked to him about the future of PGP this
summer, and he said the next release (3.0?) will not be a standalone
program, but rather a library designed to be linked into other programs.
This could drastically increase the amount of PGP-enabled software
available, especially in the non-unix world. At the time I spoke to him
(late August), PGP 3.0 development had been on hold for some time while
he finished PGPfone, but hopefully he's back at it again.
> > So we have two problems here. The first is that it would be illegal to
> > export a Linux distribution with strong encryption from the US. The
> > second is that it would be illegal to import a European-based
> > distribution with strong encryption INTO the US, albiet for different
> > reasons.
>
> This is not quite true. It's illegal to import RSA into the USA.
> This is different from "strong cryptography". This means that
> non-US-based distributions might provide non-RSA strong encryption
> by default.
You're absolutely correct. That's what I was trying to say, and I see
in hindsight I didn't say it very well. Certainly, DES and other
symmetric algorithms would work for both the US and Euro/free world
versions. The only problem would be RSA. The only solution I can see
would be using PGP-i outside the US, and RSAREF inside the US. We'd
probably have to hack up PGP a little for the US version too, to
dynamically link RSAREF and make sure the performance improvements PGP
makes on RSAREF work okay. So it wouldn't be easy.
But I don't see how we can really make a good "secure" Linux
distribution without public key cryptography, so the RSA problem must be
dealt with.
> US-based distributions should mark the cryptographic section as "not
> for export". Come to think about it: As soon as someone makes a
> "strong encryption package" that installs cleanly onto e.g.
> "SlackWare 3.0", the "Slackware 3.0" distribution automatically
> becomes an ITAR regulated item. Not that Patrick can do anything to
> prevent this....
This is something else to consider. We don't want to turn an uninvolved
bystander like Patrick into an international arms smuggler without his
consent! That's (yet another) really stupid consequence of ITAR. The
easy solution would be to construct a plug-in replacement for the
Slackware N series (the NS series?) with crypto-enhanced versions of the
standard network utilities and PGP. But in practice, we either need a
non-US-based distribution or someone with deep pockets and a lot of
courage who is willing to get knocked around the way the govt has
treated Phil Zimmerman.
> In my opinion, the only thing that really works is to equip the major
> distributions with encryption by default. With a little care Linux
> will provide for a base of encryption capable machines allowing
> a quick expansion to other machines.......
>
> Roger.
Or more likely, a new distribution will be created (or an old one
adapted) which would need to become a standard the way Slackware and Red
Hat are standards now. Such a system would be designed with security in
mind from the start... built-in shadowed passwords, PGP, ssh, Tripwire,
Kerberos, the works. There's more to building a secure system than
tossing in a copy of PGP, as all of us well know.
To rant a little... one of the most distressing problems in the Linux
world (imho) is that thousands of people who have not the time, the
inclination, or the aquired skills to be professional security
administrators are putting up Linux boxes on the Internet. And this
means thousands of sites will eventually be cracked through well-known
loopholes like the wu.ftpd bug, because their administrators simply
didn't know how to set up a secure system. A distribution designed for
security could go a long way toward preventing these problems. It would
be good for Linux, and good for the Internet community.
--
* David Stagner david_stagner@ncs.com
* National Computer Systems vox 319 354 9200 ext 6884
* Operations Division fax 319 339 6555
I disclaim my employer and I'm sure they'd disclaim me too.
