pwendt@neon.UUCP (Patrick Wendt) (06/05/90)
Hi !
I'm searching for the original C-source of the crypt()-routine
which crypts the passwords for /etc/passwd. - I've written several
crypt-programs for other mashines and even such non-recursive-
algorithms, but I've never seen the original UNIX-crypt()-algo ...
Does someone have some information how THIS algo works ...?!?!
A source-code of the crypt() would be very welcome ...
Greetings ... Pat !
-----------------------------------------------------------------------------
- Domain: root@chamber.UUCP (pwendt@chamber.UUCP) ; Zombie's Burial Chamber -
- Bang .: ..!ira.uka.de!smurf!gopnbg!tmpmbx!einoed!utopia!neon!chamber!root -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- Human Zombie ; Alternate: pwendt@neon.UUCP ; Neon Research Caboose -
- (Patrick Wendt) ; .!tmpmbx!einoed!utopia!neon!pwendt ; Berlin, W-Germany -
-----------------------------------------------------------------------------
Earth 2147, the legacy of the metal wars,
when men fought machine, and machine won ...shwake@raysnec.UUCP (Ray Shwake) (06/09/90)
In article <1139@neon.UUCP> pwendt@neon.UUCP (Patrick Wendt) writes: > >I'm searching for the original C-source of the crypt()-routine >which crypts the passwords for /etc/passwd. - I've written several >crypt-programs for other mashines and even such non-recursive- >algorithms, but I've never seen the original UNIX-crypt()-algo ... The export of encryption technology is covered by law and regulation with the intent that it not fall into the "wrong hands". West Germany, as a member of COCOM, has similar restrictions. Not only is the source code to crypt covered by these restrictions, one can not even export the BINARIES except to certain countries, and even then often requires an export license. If you ever get access to this stuff, you probably shouldn't have. 8-)
e89hse@rigel.efd.lth.se (06/11/90)
In article <56@raysnec.UUCP>, shwake@raysnec.UUCP (Ray Shwake) writes: >In article <1139@neon.UUCP> pwendt@neon.UUCP (Patrick Wendt) writes: >> >>I'm searching for the original C-source of the crypt()-routine >>which crypts the passwords for /etc/passwd. - I've written several >>crypt-programs for other mashines and even such non-recursive- >>algorithms, but I've never seen the original UNIX-crypt()-algo ... > >The export of encryption technology is covered by law and regulation >with the intent that it not fall into the "wrong hands". West Germany, >as a member of COCOM, has similar restrictions. But are even the stuff to crypt() macros covered by that COCO-stuff. I know crypt(1) is covered but crypt(2) is used by most systems for the pwd file. Anyhow does anyone have a C-source to a program that can crupt ASC-II files with reasonable security using a keyword or something like that. Is there any encryption standard when one want to send E-mail? Henrik Sandell
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/12/90)
In article <56@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >>I'm searching for the original C-source of the crypt()-routine >>which crypts the passwords for /etc/passwd. >The export of encryption technology is covered by law and regulation >with the intent that it not fall into the "wrong hands". >Not only is the source code to crypt covered by these restrictions, one >can not even export the BINARIES except to certain countries, ... Of course this neglects some relevant facts: crypt() is just DES with a minor tweak. DES has been published. crypt() has been described in technical journals. Public-domain reimplementations of crypt() are available. UNIX crypt() used to be shipped unrestricted before the lawyers got involved and started to worry about it. The export control concerns are solely due to legal considerations and government bureaucracy, not because anyone is seriously worried about crypt() "falling into the wrong hands".
bai@iesd.auc.dk (Bo Nygaard Bai) (06/13/90)
In article <13087@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >The export control concerns are solely due to legal considerations >and government bureaucracy, not because anyone is seriously worried >about crypt() "falling into the wrong hands". Don't forget protectionism. This is, as i see it, the only possible reason. What is an algorithm with export restrictions doing in UNIX ? Secure NFS, mail etc. uses some form of the DES algorithm. When a SUN workstation leaves the US it has no des(1) or crypt(1), and no DES chip. This makes it virtually impossible to use secure NFS. If DES can't be used outside of the US, then no part of UNIX software should depend on it. DES must be be released globally, or be removed totally from UNIX and replaced by a globally available encryption standard. -- .___ o .__ | | Bo Nygaard Bai | Department of Computer Science ,_//( |__. | | |/ | | University of Aalborg (AUC) / | \ ___| | |__ |\ nature | bai@iesd.auc.dk | DENMARK A U C
jim@cs.strath.ac.uk (Jim Reid) (06/13/90)
In article <BAI.90Jun12185622@dirac.iesd.auc.dk> bai@iesd.auc.dk (Bo Nygaard Bai) writes: In article <13087@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >The export control concerns are solely due to legal considerations >and government bureaucracy, not because anyone is seriously worried >about crypt() "falling into the wrong hands". Don't forget protectionism. This is, as i see it, the only possible reason. Rubbish. What Doug Gwyn says above is absolutely right. Software to implement DES has been openly published and the DES specification will be available from any decent reference library. What could possibly be protectionist about something that is so freely available? DES is anything but a trade or military secret. What is an algorithm with export restrictions doing in UNIX ? Crypt(1) and crypt(3) have been around in UNIX for far longer than the US export regulations on encryption software. The crypt() routine continues to be exported by US vendors since it is used for login authentication rather than encryption. Secure NFS, mail etc. uses some form of the DES algorithm. When a SUN workstation leaves the US it has no des(1) or crypt(1), and no DES chip. This makes it virtually impossible to use secure NFS. This is no bad thing considering how insecure "secure" NFS is. Jim
rsalz@bbn.com (Rich Salz) (06/26/90)
In <13224@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: |In article <25087@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: |>Apparently, no one may ship any DES code out of the US, even if the |>code was obtained from outside the US in the first place. | |Sure you can, but you have to get an export license first. |Export licenses will be issued upon request for products containing |DES, although only on a unit item basis (i.e. not a blanket license). | |The folks enforcing the laws cannot reasonably be blamed for the |stupidity of the laws. Unfortunately, they are not laws, but regulations. It's usually easier to get laws changed. /rich $alz, who once tried to legally export DES after a minor mistake in what used to be called mod.sources -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.