From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev)
Subject: Re: Legal Stuff!
Reply-To: bontchev@fbihh.informatik.uni-hamburg.de
Organization: Virus Test Center, University of Hamburg
Date: 21 Dec 92 22:29:06 GMT

amanda@intercon.com (Amanda Walker) writes:

> > (I just wonder how all those crypt(3) functions in the Unixes around 
> > were exported...)

> They weren't.  Export versions of UNIX have the crypt(3) functions removed
> from the C libraries.  The login program (which uses crypt(3) internally to 

Very funny... Now, our system, which is a DEC Ultrix, running on a
VAX, -does- have the crypt(3) function... The funnier thing is that it
doesn't have the crypt(1) program, which is a much weaker encryptor...
On the top of that, there is a des(1) program! (Well, I'll have to
check, maybe des(1) is in /usr/local/bin and has been put there by the
sysadmin, who has got one of the zillions free DES implementations,
available on the net...)

> authenticate passwords) turns out to be OK, because it cannot be used to 
> encrypt or decrypt information.  I have seen it reported in print that there 

Ah, but you should be able to recompile login(1) and how to do that if
crypt(3) is not available?

> > Fortunately, the USA is not the only country that has programmers, so 
> > there are plenty of free DES implementations around. I really cannot 
> > understand why RIPEM is not available for anonymous ftp, without the DES 
> > and the RSAREF stuff. Anybody should be able to plug in additional 
> > DES- and RSAREF-compatible modules... 

> This possibility is being explored.  Making it available without DES included 
> is not a problem.  Making it available without RSAREF, but still assuming the 
> *use* of RSA in its operation, may not be enough to satisfy RSA's lawyers.  
> However, we shall see how this develops.  I hope that something along these 
> lines can be worked out.

Somebody else just explained me in private e-mail that this is even
less likely... It seems that the NSA is -very- reluctant to allow
export of programs that have "hooks" for user-supplied encryption
software... For instance, there is usually no problem to export a
program that provides DES encryption using an arbitrary key, but NOT
ON ARBITRARY DATA! (By "no problem", I mean that you can get the
permission without problems, not that you don't need a pemission...)
In the same time, it is extremely unlikely that you'll be permitted to
export a program that does not perform encryption at all, but has
"hooks" for the user to plug in his/her own implementation of DES or
whatever! On the top of that, there seem to be no written laws or
regulations about this; my correspondents (there were two of them) had
got this feeling by personal experience...

As an example, the Kerberos implementation that is allowed to be
exported by DEC has not only the encryption routines removed - it has
even the -calls- to those routines removed! So, you cannot just add
encryption to it...

Regards,
Vesselin
-- 
Vesselin Vladimirov Bontchev          Virus Test Center, University of Hamburg
Tel.:+49-40-54715-224, Fax: +49-40-54715-226      Fachbereich Informatik - AGN
< PGP 2.1 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C
e-mail: bontchev@fbihh.informatik.uni-hamburg.de    D-2000 Hamburg 54, Germany
Newsgroups: alt.security.pgp,sci.crypt