Non-ATT 'crypt(3)'
Geoff Arnold
Does anyone know of a version of 'crypt(3)' which doesn't contain
AT&T code, and is therefore not bound by U*ix licensing strictures?
Something less general (e.g. just password-size data blocks) would be
just fine.
--
#include <sys/disclaimer.h> /* co. lawyers: will this do? */
Geoff Arnold * * * Quick: 617-863-8870 x136 (but ya gotta catch me!)
Sun Microsystems Inc.***** Slower: {hplabs,ihnp4,nsc,pyramid}!sun!suneast!geoff
East Coast Division. * * * Slowest:One Cranberry Hill, Lexington, MA 02173
Frederick M. Avolio
> [line eater food]
> Does anyone know of a version of 'crypt(3)' which doesn't contain
> AT&T code, and is therefore not bound by U*ix licensing strictures?
Let us be careful about posting something to a world-wide network that
might break State Department "rules."
--
Fred @ DEC Ultrix Applications Center {decvax,seismo,cbosgd}!decuac!avolio
Leif Samuelsson
>Let us be careful about posting something to a world-wide network that
>might break State Department "rules."
As far as I know, our State Department has no "rules" concerning crypt
programs.
----
Leif Samuelsson ..enea!erix!erisun!leif
Ericsson Information Systems AB, Advanced Workstations Division
S-172 93 SUNDBYBERG, Sweden (59 19' N / 17 57' E)
----------------------
! !
! | !
! !
! This is not a pipe !
----------------------
Leif Samuelsson
>The "definitive" advice that we've
>received from corporate lawyers is that it is legal to add the code back in,
>even from an old version of the UNIX System.
If this is true, would UEL be willing to ship copies of the old
crypt routines to people in Europe who hold the right licences?
Douglas H. Price
devices, procedures, etc. This is, of course, intended to prevent 'rival
powers' from taking advantage of our more open ways of doing things. It was
much easier to draft a law forbidding the export of ALL items of this type
rather than try to split hairs as to what was harmless and what wasn't.
Now I personally don't agree with the concept that the easiest way of
accomplishing a goal is necessarily the right way of doing it. I UNDERSTAND
why they did it, but don't AGREE with how it was done. So, I suspect we will
just have to get used to this kind of sloppiness on the part of our governments.
We see this in Europe as well, where each of your national telephone and
telegraph ministries jealously guard their right to dictate there own data
and networking protcols, the result of which is that most international data
in Europe is switched through TELENET in California!
--
Douglas H. Price
Analysts International Corp.
@ AT&T Bell Laboratories
..!ihnp4!ihnp3!dhp
Geoff Arnold
writes:
> ... Further, any competent programmer
> can reproduce the crypt(3) code in an afternoon from a functional description.
Oh really? The problem is, the only functional description other than the
code is the 'crypt(3)' man page, which vaguely says that the 'salt' is
"used to perturb the DES algorithm in one of 4096 different ways". Can you
deduce the algorithm without looking at the code? And what would be
the legal position if someone looked at the code, wrote down a suitable
functional description and gave it to you? My guess is that either they
would be publishing it (and thus be in breach of their AT&T license) or
acting as your agent, in which case it's as though you did it yourself. As
the man page points out, the routine incorporates "variations intended
(among other things) to frustrate use of hardware implemen-
tations of the DES for key search." (Gee - by quoting THAT am I in trouble?
Probably not - this could be construed as a review, I guess.) Presumably
this whole question is one of the "other things" mentioned.
Now a further question. How have the Un*x clones gone about it? Do systems
such as Coherent, UNOS, etc. use an equivalent algorithm (i.e. could I pick
up a Un*x passwd file, drop it on one of their systems and just use it)?
--
#include <sys/disclaimer.h> /* co. lawyers: will this do? */
Geoff Arnold =-=-= Quick: 617-863-8870 x136 (but ya gotta catch me!)
Sun Microsystems Inc.-=-=- Slower: {hplabs,ihnp4,nsc,pyramid}!sun!suneast!geoff
East Coast Division. =-=-= Slowest:One Cranberry Hill, Lexington, MA 02173
Steve Schlaifer x3171 156/224
> >Let us be careful about posting something to a world-wide network that
> >might break State Department "rules."
>
> As far as I know, our State Department has no "rules" concerning crypt
> programs.
>
> ----
patch disks for Ridge's ROS UN*X system come in two flavors; one for U.S.
distribution and the other for foreign distribution. I have been told that
the only difference between them is the encryption algorithm used.
Steve Schlaifer {smeagol|group3}!jplgodo!steve
Bill.Stewart.4K435.x0705
>Alex Osadzinski, Unix Europe Ltd, London, England
>writes:
>> ... Further, any competent programmer
>> can reproduce the crypt(3) code in an afternoon from a functional description.
>
>Oh really? The problem is, the only functional description other than the
>code is the 'crypt(3)' man page, which vaguely says that the 'salt' is
>"used to perturb the DES algorithm in one of 4096 different ways". Can you
>deduce the algorithm without looking at the code?
The important thing is to get the interface right; for normal
applications it's unnecessary to pass crypt(3)'ed passwords between
systems; if you depend on that then propagate your own crypt routine as
well as your application. The salt business has two main purposes:
- make it impossible to use DES hardware to decrypt
(software is much slower, and if the speculated-about
NSA trapdoor exists, this may make it fail.)
- produce different cyphertexts for identical plaintext
encrypted with identical keys - this makes cryptanalysis
much more difficult, and makes it hard to tell that
you're using the same passwords on N different machines.
As long as you've got the interfaces correct, the internals don't
really matter much.
--
# Bill Stewart, AT&T Bell Labs 2G-202, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
David Morton
Expires:
References: <1...@suneast.uucp> <7...@decuac.UUCP> <4...@brl-tgr.ARPA> <uel.522>
Sender:
Reply-To: da...@ecrcvax.UUCP (David Morton)
Followup-To:
Distribution:
Organization: European Computer-Industry Research Centre, Munchen, W. Germany
Keywords:
In article <uel.522> alex@uel (Alex Osadzinski ) writes:
>Seriously, this business of removing the decryption code from international
>versions of UNIX Systems is a pain in the rectum for everybody.
I know of at least two companies in Germany who shipped this
code before the State Dept decided it was "a breach of national security"
or whatever the reason was for the decision. One of these companies was
obviously unaware at that time of the breach and promptly "upgraded"
customers to a version without the 'crypt' as soon as it was generally
known. Note these were not necessarily both German companies.
One in fact had to stop shipping, according to my sources.
Someone should tell the State Dept. that the stable door has been open
for the past 8 years at least and closing it now only makes them look
more stupid than they already are.
--
Dave Morton
Tel. + (49) 89 - 92699 - 139
CSNET: dave%ecrcva...@germany.csnet
UUCP: seismo!mcvax!unido!ecrcvax!dave
Jay R. Ashworth
make a substitute crypt(3) program produce cyphertext which an at&t
crypt program can decipher. (or, at least, that's what I *thought* he was
talking about...)
His point seems to be well taken, for the only problem caused would
be the inability to decrypt something which another site has sent you, to
which you know the key. However, if you *have* source code for a crypt
program, you can just send them a copy (assuming legalities permit), and
ask them to use *it*, instead of the 'standard' version. A small logistics
prolem, maybe, but no other ones that I can see. Of course, by legalities
above, I meant copyrights, etc., not legal restrictions on encryption
technology. I refuse to comment on that, the NSA might be listening :-).
-- jra
--
Jay R. Ashworth Proma Software j...@jc3b22.UUCP
Programmer/Analyst 9189 Park Blvd. (813) 399-1045
Boy Genius (:-) Seminole FL 33544 (So they tell me)
Disclaimer: The opinions, if any, expressed in this article, if any,
are not those of my employer, if any, or anybody else,
and probably resulted from Coca-Cola (Coca-Cola is a reg. tm
of Coca-Cola USA) dripping down my keyboard.