edc@ALTOS.COM (Eric Christensen) (06/17/88)
O.K., I'm in a rowdy mood, so I think I'll start a debate here. Gotta liven up this newsgroup a bit while we're waiting for the vote tally :-) I've got an issue with the use of the crypt() routines in Elm. These routines are not available to anyone outside of the United States. Now, I don't know about anyone else, but I've got several international offices that do / want to use Elm. My suggestion is that we replace the crypt() calls with a public domain routine. It won't be compatible with the crypt() routine, but I don't think that that will really be an issue. Actually, I was reminded of this by Robert Claeson at PVAB in Sweden. He has generously volenteered to supply public domain DES and enigma functions which we could utilize. This should be done before an offical 2.0 release. We don't really want to have 2 incompatible encryption routines in Elm. Yes, I know the 2.0 gamma is out there using crypt(). But does this "renegade", as Dave calls it, software really count? I would assume that everybody would upgrade to the official release when it comes out. Any anyone who doesn't...... well, what can I say. They're on their own. Comments? Flames? -- +-------------------------+---------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +---------------------------------------------------+ | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | | San Jose, Ca. 95131 | Feature - A Documented Bug | +-------------------------+---------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them | +-----------------------------------------------------------------------------+
blair@obdient.UUCP (Doug Blair) (06/19/88)
In article <470@altnet.ALTOS.COM>, edc@ALTOS.COM (Eric Christensen) writes: > I've got an issue with the use of the crypt() routines in Elm. These routines > are not available to anyone outside of the United States. Now, I don't know > My suggestion is that we replace the crypt() calls with a public domain routine. > This should be done before an offical 2.0 release. This is a valid point. Many domestic sites, including those running Micrport SysV/[AT/386] and Xenix, don't have crypt on their systems unless they have specifically requested it from the supplier. There was a PD crypt clone posted to alt.sources a few weeks ago which might be adaptable and built into ELM - or perhaps it will be sufficient to use some sort of elementary encoding feature a la rot13. In any event ELM should NOT contain such an obvious system dependency. Doug ___ _ _ _ _ / \ | | | | |_| _| |_ Doug Blair_______312-653-5527 | | || |_ ___ _| | _ ___ __ |_ _| Obedient Software Corporation | | || ==\ / ==\ /== | | | / ==\ | \ | | 1007 Naperville Road_________ \___/ |___/ \___/ \___| |_| \___/ |_|_| |_| Wheaton, Illinois 60187______
mark@clout.Jhereg.MN.ORG (Mark H. Colburn) (06/20/88)
In article <470@altnet.ALTOS.COM> edc@ALTOS.COM (Eric Christensen) writes: > >I've got an issue with the use of the crypt() routines in Elm. These routines >are not available to anyone outside of the United States. Now, I don't know >about anyone else, but I've got several international offices that do / want to >use Elm. Hmmmm. The last time I looked, I thought that all versions of Unix were supplied with a crypt command. It is just that there is one version made for use in the U.S., and another which is distributed abroad. Therefore there are crypt libraries on all systems, but they may be incompatible. Is this correct? This would still cause a problem if you were attempting to send crypted mail to someone who has an incompatible crypt, so I support Eric's idea of using a PD version of crypt rather than relying on the potentially different versions of crypt that are distributed with the system. -- Mark H. Colburn mark@jhereg.chi.il.us mark@jhereg.mn.org ..!chinet!jhereg!mark
edc@ALTOS.COM (Eric Christensen) (06/20/88)
In article <278@clout.Jhereg.MN.ORG> mark@clout.Jhereg.MN.ORG (Mark H. Colburn) writes: > >Hmmmm. The last time I looked, I thought that all versions of Unix >were supplied with a crypt command. It is just that there is one >version made for use in the U.S., and another which is distributed >abroad. Therefore there are crypt libraries on all systems, but they >may be incompatible. Is this correct? It is true that some UNIX vendors have a "quasi-crypt" that they supply to international customers, but many do not. You are correct that the quasi-crypt is incompatible with the real crypt, and this poses a big problem for elm. >This would still cause a problem if you were attempting to send >crypted mail to someone who has an incompatible crypt, so I support >Eric's idea of using a PD version of crypt rather than relying on the >potentially different versions of crypt that are distributed with the >system. I propese that we select a fairly stable PD crypt which we can build into the Elm sources. That way "Elm is Elm" no matter where you are. I am currently evaluating several crypts for this purpose. If anyone has any suggestions, or a favorite quasi-crypt function, I'd love to hear from you. I'll post my findings and proposal later this week. -- +-------------------------+---------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +---------------------------------------------------+ | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | | San Jose, Ca. 95131 | Feature - A Documented Bug | +-------------------------+---------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them | +-----------------------------------------------------------------------------+
jrmacmillan@lily.waterloo.edu (John R. MacMillan) (06/21/88)
In article <470@altnet.ALTOS.COM> edc@ALTOS.COM (Eric Christensen) writes: |My suggestion is that we replace the crypt() calls with a public |domain routine. It won't be compatible with the crypt() routine, but |I don't think that that will really be an issue. Sounds great to me. Of course, I'm slightly biased, what with not being able to use the US crypt() regardless :-) -- John R. MacMillan jrmacmillan@lily.waterloo.edu "I was _roasted_!!" ..!watmath!lily!jrmacmillan -- M&Ms Peanut
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (06/21/88)
In article <485@altnet.ALTOS.COM> edc@altnet.ALTOS.COM (Eric Christensen) writes: >I am currently evaluating several crypts for this purpose. If anyone has any >suggestions, or a favorite quasi-crypt function, I'd love to hear from you. I think including a crypt command with elm is just asking for trouble. The differences in the results of shifts and rotates among compilers on various architectures is almost guaranteed to cause the routing to break somewhere along the line (as in 8/9/10 bit chars, and the corresponding differences in their int's, etc). As far as I am concerned, if two people want to send each other encrypted mail they should implement their own compatable (with each others) crypt(1) replacement. I don't think encryption should be part of the UA. Let's use the man hours to develop some bullet proof parsing for return addresses. We can always add the bells later. -- {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA
edc@ALTOS.COM (Eric Christensen) (06/21/88)
In article <10291@ncc.Nexus.CA> lyndon@ncc.nexus.ca (Lyndon Nerenberg) writes: > >As far as I am concerned, if two people want to send each other encrypted >mail they should implement their own compatable (with each others) >crypt(1) replacement. I don't think encryption should be part of the UA. >Let's use the man hours to develop some bullet proof parsing for return >addresses. We can always add the bells later. Ah, I disagree on a couple of counts. For one, If there is going to be an encryption option, it MUST be consistent between systems. There's nothing worse than getting an encrypted message and not being able to decrypt it. (I know, I've been there all too often.) Second, the encryption is already part of Elm 2.0. The only issue is Dave's use of the crypt() routine. There are plenty of portable public domain encryption routines that we can simply snarf, with a minimum of time. -- +-------------------------+---------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +---------------------------------------------------+ | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | | San Jose, Ca. 95131 | Feature - A Documented Bug | +-------------------------+---------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them | +-----------------------------------------------------------------------------+
andre@targon.UUCP (Andre van Dalen) (06/22/88)
I use elm (extracted from the novavax sources) and it's great. As you probably note (see top of page) my site is in Holland, Europe. When I type crypt from the shell command line the system tells me that crypt is not supported outside of the united states, but the [encode] ecrypting of elm works. I don't know if it is the same as inside the USA though, but at least there must be a crypt call in the c library. ~----~ |m AAA DDDD It's not the kill, but the thrill of the chase. ~|d1|~@-- AA AAvv vvDD DD Segment registers are for worms. ~----~ & AAAAAAAvv vvDD DD ~~~~~~ -- AAA AAAvvvDDDDDD Andre van Dalen, uunet!mcvax!targon!andre -- ~----~ |m AAA DDDD It's not the kill, but the thrill of the chase. ~|d1|~@-- AA AAvv vvDD DD Segment registers are for worms. ~----~ & AAAAAAAvv vvDD DD ~~~~~~ -- AAA AAAvvvDDDDDD Andre van Dalen, uunet!mcvax!targon!andre
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (06/24/88)
In article <492@altnet.ALTOS.COM> edc@altnet.UUCP (Eric Christensen) writes: >Ah, I disagree on a couple of counts. And I disagree in turn :-) > For one, If there is going to be an >encryption option, it MUST be consistent between systems. There's nothing >worse than getting an encrypted message and not being able to decrypt it. Exactly my point. I can think of three mailers (excluding elm) that implement their own mutually incompatible encryption system. What we don't need is a fourth one! If two users want to exchange encrypted messages, let THEM agree on how to do it. As a mail system administrator (for eight machines spread across four sites) I do *not* want to spend my time explaining why the mailer has an encryption feature, but that the user can't use it to send encrypted mail to foo!friend because s/he is using UA 'y' which is not compatible with UA 'z'. -- {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA
lyndon@ncc.Nexus.CA (Lyndon Nerenberg) (06/24/88)
In article <407@targon.UUCP> andre@targon.UUCP (Andre van Dalen) writes: > >When I type crypt from the shell command line the system tells me that >crypt is not supported outside of the united states, but the [encode] >ecrypting of elm works. I don't know if it is the same as inside the >USA though, but at least there must be a crypt call in the c library. Oh oh... Do I take this to mean the Elm provides in and of itself two incompatible encryption schemes? Now we have to make Elm choose one over the other based upon the destination addresses. I rest my case. -- {alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA
chip@vector.UUCP (Chip Rosenthal) (06/24/88)
There are two issues to this encryption business. The one being focused
on is sending encrypted mail between machines.
The other issue is that some systems are not *shipped* with crypt. SCO
XENIX for example. However, it was real easy to get. One phone call to
SCO support and I had it within a week.
I'm inclined to remove the assumption from elm that the system has crypt
available. This could be done by including a crypt() with the sources.
Maybe, however, it would be better handled with some #ifdef's.
--
Chip Rosenthal /// chip@vector.UUCP /// Dallas Semiconductor /// 214-450-0400
{uunet!warble,sun!texsun!rpp386,killer}!vector!chip
I won't sing for politicians. Ain't singing for Spuds. This note's for you.sewilco@datapg.DataPg.MN.ORG (Scot E. Wilcoxon) (06/26/88)
In article <10291@ncc.Nexus.CA> lyndon@ncc.nexus.ca (Lyndon Nerenberg) writes: ... >As far as I am concerned, if two people want to send each other encrypted >mail they should implement their own compatable (with each others) >crypt(1) replacement. I don't think encryption should be part of the UA. ... Therefore, a [person,site],en-/decryption_routine table is needed. A mutually agreeable decryption routine name should also be in the encryption header. -- Scot E. Wilcoxon sewilco@DataPg.MN.ORG {amdahl|hpda}!bungia!datapg!sewilco Data Progress UNIX masts & rigging +1 612-825-2607 uunet!datapg!sewilco
edc@ALTOS.COM (Eric Christensen) (06/27/88)
In article <10291@ncc.Nexus.CA> lyndon@ncc.nexus.ca (Lyndon Nerenberg) writes: > >As far as I am concerned, if two people want to send each other encrypted >mail they should implement their own compatable (with each others) >crypt(1) replacement. I don't think encryption should be part of the UA. > I have to agree with Lyndon on this one. After evaluating several diferent ways to encrypt messages, I kept coming back to the same problem. Whatever we do for Elm will be incompatible with all other mail systems (few of which have any encryption at all). My proposed solution: remove the crypt option from Elm. Wait!!!! Don't flame me yet! Besides the compatability problems there is another concern here. It's very easy to add feature after feature to a package like Elm. This is fine up to a point, but when you start adding features that most people won't or can't use, you're not increasing the worth of the package at all. In fact, you may be decreasing it's worth, based on the fact that you're adding more code, which makes it harder to maintain and keep portable (can you sy 80286? :-). If nobody comes up with a real good reason to keep the crypt calls, I'm going to yank them (or at least ifdef them out). And I don't plan on spending any more time working on this issue. After all, there are "real" bugs to be fixed, and a release to get out. -- +-------------------------+---------------------------------------------------+ | Eric D. Christensen | Email: edc@altnet.altos.com (uunet!altnet!edc) | | Altos Computer Systems +---------------------------------------------------+ | 399 West Trimble Road | Definitions: Bug - An Undocumented Feature | | San Jose, Ca. 95131 | Feature - A Documented Bug | +-------------------------+---------------------------------------------------+ | These views aren't Altos' - They're mine, all mine, and you can't have them | +-----------------------------------------------------------------------------+
jeff@cjsa.UUCP (C. Jeffery Small) (06/27/88)
In article <1060@datapg.DataPg.MN.ORG>, sewilco@datapg.DataPg.MN.ORG (Scot E. Wilcoxon) writes: > In article <10291@ncc.Nexus.CA> lyndon@ncc.nexus.ca (Lyndon Nerenberg) writes: > ... > >As far as I am concerned, if two people want to send each other encrypted > >mail they should implement their own compatable (with each others) > >crypt(1) replacement. I don't think encryption should be part of the UA. > ... > > Therefore, a [person,site],en-/decryption_routine table is needed. A mutually > agreeable decryption routine name should also be in the encryption header. I think this is a good idea. Keeping the decryption routine out of ELM will solve a lot of future problems. This external specification allows individuals or groups to agree to use a customized encryption routine for specialty purposes and allows sites without crypt(1) to request the use of a special routine by those mailing to them. I assume that Scot is suggesting something along the lines of an XCRYPT: crypt_routine_name mail header line. With this thought in mind, we might select a PD en/decryption program to package as an auxillary program with ELM and call it elmcrypt or some such. I would also suggest that in the event that no special encryption routine is specified, the default should be to use crypt(1) or issue a warning message when crypt(1) is unavailable. -- Jeffery Small (203) 776-2000 UUCP: uunet!---\ C. Jeffery Small and Associates ihnp4!--- hsi!cjsa!jeff 123 York Street, New Haven, CT 06511 hao!noao!---/
woerz@iaoobelix.UUCP (Dieter Woerz) (06/30/88)
In article <370@vector.UUCP> chip@vector.UUCP (Chip Rosenthal) writes: >There are two issues to this encryption business. The one being focused >on is sending encrypted mail between machines. > >The other issue is that some systems are not *shipped* with crypt. SCO >XENIX for example. However, it was real easy to get. One phone call to >SCO support and I had it within a week. > ... I noticed everyone saying that not every host has a crypt command. I agree totally on that, as our Suns and uVAXes here in Europe don't have the crypt command. But nobody mentioned that every UNIX system has a crypt function to be used for password encryption. And as far as I have noticed, this seem to work the same on all machines. We have ported password files from VAXen to Suns and HPs and all users could log in under their normal passwords. So you seem to be able to use the crypt feature at least with every elm in the world, ok not with every mailer in the world. But normally I use this feature on our local machines to tell others about a changed password, so that noone can accidently read it. ------------------------------------------------------------------------------ Dieter Woerz Fraunhofer Institut fuer Arbeitswirtschaft und Organisation Abt. 453 Holzgartenstrasse 17 D-7000 Stuttgart 1 W-Germany BITNET: iaoobel.uucp!woerz@unido.bitnet UUCP: ...{uunet!unido, pyramid}!iaoobel!woerz
barry@n0atp.UUCP (Barry S. Berg) (06/30/88)
In article <520@altnet.ALTOS.COM> edc@altnet.UUCP (Eric Christensen) writes: >In article <10291@ncc.Nexus.CA> lyndon@ncc.nexus.ca (Lyndon Nerenberg) writes: >> >>As far as I am concerned, if two people want to send each other encrypted >>mail they should implement their own compatable (with each others) I agree with Lyndon as well on this one. >My proposed solution: remove the crypt option from Elm. Wait!!!! > [... justification ....] In fact, you may >be decreasing it's worth, based on the fact that you're adding more code, which >makes it harder to maintain and keep portable (can you sy 80286? :-). Agreed... especially since I have a 286... > >If nobody comes up with a real good reason to keep the crypt calls, I'm going >to yank them (or at least ifdef them out). And I don't plan on spending any >more time working on this issue. After all, there are "real" bugs to be fixed, >and a release to get out. What I propose is to put a dummy local routine in. IBM calls this a user exit on their mainframe software. The local definiation would overide the external definition, not a lot of code would be generated, and the system would allow the use of crypt(1) or a PD crypt if desired. The following would be a code sample. #ifndef CRYPT /* if std encryption not desired */ char * crypt(key, salt) char *key, *salt; { #ifndef LOCAL_CRYPT return(key); #else /* put your locally defined code here */ #endif } void setkey(key) char *key; { #ifndef LOCAL_CRYPT return; #else /* put your locally defined code here */ #endif } void encrypt(block, edflag) char *block; int edflag; { #ifndef LOCAL_CRYPT return; #else /* put your locally defined code here */ #endif } #endif By undefing CRYPT and LOCAL_CRYPT selectively all sides could be accomodated, still maintaining a consistant interface, and standard code distribution. Also, the overhead in code size would be faily small. There will also be specific code hacks for the 80286 systems. Can we isolate them as follows. This will work automatically for SCO Xenix, no defines needed. #ifndef I_286 regular way #else for the 286 #endif Comments?? -- Barry S. Berg DOMAIN: barry@n0atp.N0ATP.MN.ORG N0ATP Packet Radio Gateway UUCP: {...}amdahl!bungia!n0atp!barry "Speech is civilization itself--it is silence which isolates." --Thomas Mann "Moderation in all things, most especially moderation." --Author as yet unknown.
pengo@tmpmbx.UUCP (Hans H. Huebner) (07/01/88)
In article <196@iaoobelix.UUCP> woerz@iaoobelix.UUCP (Dieter Woerz) writes: >But nobody mentioned that every UNIX system has a crypt function to >be used for password encryption. And as far as I have noticed, this >seem to work the same on all machines. We have ported password files >from VAXen to Suns and HPs and all users could log in under their >normal passwords. >So you seem to be able to use the crypt feature at least with every >elm in the world, ok not with every mailer in the world. But normally >I use this feature on our local machines to tell others about a >changed password, so that noone can accidently read it. For more speculation: As far as i know, you *may* export binaries from the USA which use crypt(), but you may *not* export the library functions or the crypt(1) command. Why this is so is somehow obvious - Unix needs the standard crypt function for the password encoding, but the [insert your favourite US secret service here] doesn't want non-amerikans using their encryption scheme for their private stuff. OK, this is the hard world, and we can't change it (except by doing a complete and compatible rewrite of all encryption functions - any volunteers?) I think encrypted mail can be quite handy, especially if you either know that the machine you're using is not safe or if you don't trust your sysop. Calling an external program would be the best approach in my opinion, especially because any two persons can use their own favoured obscure encryption utility. -Hans -- Hans H. Huebner, netmbx | PSIMail: PSI%026245300043100::PENGO Woerther Str. 36 | DOMAIN: pengo@tmpmbx.UUCP D-1000 Berlin 20, W.Germany | Bang: ..!{pyramid,unido}!tmpmbx!pengo Phone: (+49 30) 332 40 15 | BITNET: huebner@db0tui6
sow@eru.mt.luth.se (Sven-Ove Westberg) (07/06/88)
In article <10291@ncc.Nexus.CA> lyndon@ncc.nexus.ca (Lyndon Nerenberg) writes: |In article <485@altnet.ALTOS.COM> edc@altnet.ALTOS.COM (Eric Christensen) writes: |As far as I am concerned, if two people want to send each other encrypted |mail they should implement their own compatable (with each others) |crypt(1) replacement. I don't think encryption should be part of the UA. |Let's use the man hours to develop some bullet proof parsing for return |addresses. We can always add the bells later. Address parsing is NOT a matter for the UA either. |-- |{alberta,pyramid,uunet}!ncc!lyndon lyndon@Nexus.CA Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden. UUCP: {uunet,mcvax}!enea!cad.luth.se!sow ARPA: sow%cad.luth.se@ucbvax.berkeley.edu (only dumb ARPA mailers) Internet: sow@cad.luth.se Bitnet: sow%cad.luth.se@sekth
jrmacmillan@lily.waterloo.edu (John R. MacMillan) (07/10/88)
In article <1095@luth.luth.se> Sven-Ove Westberg <sow@cad.luth.se> writes: | |Address parsing is NOT a matter for the UA either. I beg to differ; how does Elm know who to reply to if it can't parse addresses? -- John R. MacMillan jrmacmillan@lily.waterloo.edu "I was _roasted_!!" ..!watmath!lily!jrmacmillan -- M&Ms Peanut
sow@eru.mt.luth.se (Sven-Ove Westberg) (07/20/88)
In article <5135@watcgl.waterloo.edu> jrmacmillan@lily.waterloo.edu (John R. MacMillan) writes: |In article <1095@luth.luth.se> Sven-Ove Westberg <sow@cad.luth.se> writes: || ||Address parsing is NOT a matter for the UA either. | |I beg to differ; how does Elm know who to reply to if it can't parse |addresses? It understands the structure of the header, thats all a UA has to know. Then it send it all to the TA. Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden. UUCP: {uunet,mcvax}!enea!cad.luth.se!sow ARPA: sow%cad.luth.se@ucbvax.berkeley.edu (only dumb ARPA mailers) Internet: sow@cad.luth.se Bitnet: sow%cad.luth.se@sekth
les@chinet.chi.il.us (Leslie Mikesell) (07/23/88)
In article <1151@luth.luth.se> Sven-Ove Westberg <sow@eru.luth.se> writes: >||Address parsing is NOT a matter for the UA either. >|I beg to differ; how does Elm know who to reply to if it can't parse >|addresses? >It understands the structure of the header, thats all a UA has to know. >Then it send it all to the TA. This assumes that the UA is passed something reasonable in the header (i.e. a FROM: line in a format that the TA will understand), and precludes the possibility of the UA being able to warn the user when an impossible address is specified. The former is often not the case (uucp mailers do not require any headers). The latter should be optional for cases where the TA does not re-route. Les Mikesell