geoff@suneast.uucp (Geoff Arnold) (12/04/85)
[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?
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 02173avolio@decuac.UUCP (Frederick M. Avolio) (12/06/85)
In article <124@suneast.uucp>, geoff@suneast.uucp (Geoff Arnold) writes: > [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
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (12/09/85)
> > 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." Although U.S. intellectuals have been fairly successful at selling us all down the river, there is still hope if enough citizens would realize that our government was established to serve its people, not (as in many other countries) the other way around. No agent of the government has any business restricting the flow of information among free men, or spying on its citizens, or searching their property without warrant, or many of the other things that Federal agencies have taken upon themselves. The only way to maintain what liberty still exists and regain that that has been lost, is to become aware of the oppressive acts of the bureaucracy and to NOT LET THEM GET AWAY WITH IT. The spook agencies, in particular, have felt that they are above ethics and normal law, and this is made worse by their virtual unaccountability. James Bamford's "The Puzzle Palace", although slow going in places, is a fairly accurate eye-opener for those who have not realized the extent of the U.S. government's attempt to control the flow of information. Generally the Commerce and State Department rules are based on what the DOD (NSA) tells them, and you can be assured that the NSA is not committed to the long-term benefit of humanity (via improved state of knowledge) but rather to the short-term concrete interests of a single nation. To anyone who is a supporter of the ideas on which this nation was founded, this mindless "patriotism" is counter- revolutionary. The best thing that could happen regarding data encryption would be for a cheap (fast and easy), reliable, secure encryption scheme to be universally adopted. (None of the standard UNIX software remotely qualifies.) This would not put the NSA out of business, since crib- dragging, tickling, eavesdropping on unencrypted traffic, traffic analysis, and other techniques could still be exploited, but it would sure make their budget-to-results ratio soar. There are provably secure schemes that require an impractical amount of secure key, but any information theorist worth his salt should be able to independently arrive at the ideas behind unicity distance, which is a measure of how much ciphertext is required to have a reasonable chance of successful cryptanalysis (a function of system structural complexity and key length). If one changes the key more fequently than the unicity distance, statistical attacks on the cipher stream become unprofitable, although experienced cryptanalysts should nonetheless probe a system for exploitable weaknesses before it is fielded (strong in theory may not mean strong in practice, due to a variety of potential problems such as tendency of bits to stick, susceptibility to operator error leading to isomorphic transmissions, failure to shield electronics that handles the clear text, etc.). In spite of the relative simplicity of setting up practically secure communications, amazingly enough incredibly easy-to-break systems have been and are still used for very sensitive information. Let's get these leaks plugged so we can keep snoops' noses out of our data. Meanwhile, let's question the wisdom of throttling freedom in the name of "protecting" it.
leif@erisun.UUCP (Leif Samuelsson) (12/11/85)
In article <717@decuac.UUCP> avolio@decuac.UUCP (Frederick M. Avolio) writes: >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 ! ----------------------
alex@uel (Alex Osadzinski ) (12/12/85)
This week's Datalink (a UK weekly computer rag) reports that the British Defence Ministry (MoD) is adopting UNIX System V. However, it intends to produce a highly secure variant, doubtless for its own nefarious purposes. The nicest thing about the article is a quote from a spokesperson saying how pleasant it will be to take the sanitised UNIX code that we get in Europe and make it infinitely more secure than the original item. Seriously, this business of removing the decryption code from international versions of UNIX Systems is a pain in the rectum for everybody. We have similar problems with the encryption chips being removed from, say, automatic teller machines when they're shipped here. 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. Further, any competent programmer can reproduce the crypt(3) code in an afternoon from a functional description. Such is life. Alex Osadzinski, Unix Europe Ltd, London, England ...ukc!uel!alex ...attunix!uel!alex
leif@erisun.UUCP (Leif Samuelsson) (12/16/85)
In article <522@uel> alex@uel (Alex Osadzinski ) writes: >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? --- Leif Samuelsson ..enea!erix!erisun!leif Ericsson Information Systems AB, Advanced Workstations Division S-172 93 SUNDBYBERG, Sweden (59 19' N / 17 57' E)
dhp@ihnp3.UUCP (Douglas H. Price) (12/16/85)
The U.S. has a federal law on the books forbidding the export of cryptographic 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@suneast.uucp (Geoff Arnold) (12/17/85)
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? 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@jplgodo.UUCP (Steve Schlaifer x3171 156/224) (12/17/85)
> In article <717@decuac.UUCP> avolio@decuac.UUCP (Frederick M. Avolio) writes: > >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. > > ---- I have never actually seen the "rules" but I do know that system updates and 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
wcs@ho95e.UUCP (Bill.Stewart.4K435.x0705) (12/20/85)
In article <125@suneast.uucp> geoff@suneast.uucp (Geoff Arnold) writes: >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
dave@ecrcvax.UUCP (David Morton) (12/22/85)
Summary: Expires: References: <124@suneast.uucp> <717@decuac.UUCP> <435@brl-tgr.ARPA> <uel.522> Sender: Reply-To: dave@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%ecrcvax.uucp@germany.csnet UUCP: seismo!mcvax!unido!ecrcvax!dave
jra@jc3b21.UUCP (Jay R. Ashworth) (12/26/85)
In article <357@ho95e.uucp>, Bill Stewart discusses the lack of need to
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 jra@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.