Info-PGP: PGP Digest Thursday 3 December 1992 Volume 1 : Number 35 Hugh Miller, List Manager / Moderator Info-PGP is a digested mailing list dedicated to discussion of Philip Zimmermann's `Pretty Good Privacy' (PGP) public-key encryption program for MS-DOS, Unix, VMS, Atari, Amiga, SPARC, Macintosh, and (hopefully) other operating systems. It is primarily intended for users on Internet sites without access to the `alt.security.pgp' newsgroup. Most submissions to alt.security.pgp will be saved to Info-PGP, as well as occasional relevant articles from sci.crypt or other newsgroups. Info-PGP will also contain mailings directed to the list address. To SUBSCRIBE to Info-PGP, please send a (polite) note to info-pgp-request@lucpul.it.luc.edu. This is not a mailserver; there is a human being on the other end, and bodiless messages with "Subject:" lines reading "SUBSCRIBE INFO-PGP" will be ignored until the sender develops manners. To SUBMIT material for posting to Info-PGP, please mail to info-pgp@lucpul.it.luc.edu. In both cases, PLEASE include your name and Internet "From:" address. Submissions will be posted pretty well as received, although the list maintainer / moderator reserves the right to omit redundant messages, trim bloated headers & .sigs, and other such minor piffle. I will not be able to acknowledge submissions, nor, I regret, will I be able to pass posts on to alt.security.pgp for those whose sites lack access. Due to U.S. export restrictions on cryptographic software, I regret that I cannot include postings containing actual source code (or compiled binaries) of same. For the time being at least I am including patches under the same ukase. I regret having to do this, but the law, howbeit unjust, is the law. If a European reader would like to handle that end of things, perhaps run a "Info-PGP-Code" digest or somesuch, maybe this little problem could be worked around. I have received a promise of some space on an anonymous-ftp'able Internet site for back issues of Info-PGP Digest. Full details as soon as they firm up. Oh, yes: ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; STANDARD DISCLAIMERS APPLY. Hugh Miller | Asst. Prof. of Philosophy | Loyola University Chicago FAX: 312-508-2292 | Voice: 312-508-2727 | hmiller@lucpul.it.luc.edu Signed PGP v.2.0 public key certificate available by e-mail & finger ------------------------------------------------------------------------------- Newsgroups: alt.security.pgp From: blaak@csri.toronto.edu (Raymond Blaak) Subject: Is this public or commercial pgp use? Date: 25 Nov 92 22:51:14 GMT Private use of pgp by individuals is apparently allowed. Presumably, incorporating pgp into a product and selling it without an RSA license is not allowed. If a company wants to use pgp for internal use only (like secure communications between remote locations), is this allowed without licensing? Cheers, Ray (blaak@csri.toronto.edu) =-=-=-=-=-= Newsgroups: alt.security.pgp From: strnlght@netcom.com (David Sternlight) Subject: Re: Is this public or commercial pgp use? Date: Thu, 26 Nov 1992 00:33:55 GMT WARNING: NON-ATTORNEY MAKING IT UP AS HE GOES ALONG. Raymond Blaak asks if internal company use is commercial, and therefore prohibited without a licence. If it's used by a company, i.e. for company purposes, it's commercial use since a company is a commercial entity. Internal or external would (he makes up out of whole cloth) have nothing to do with it. I suppose if I send my buddy Joe who also works for the company a PGP message about non-company activities, that would be personal use. But since one can't tell from the outside, the presumption in that case would have to be that it wasn't. That would be based on the notion of preponderance of evidence (that most internal company correspondence is business-oriented). Thus one would have to prove it's personal to be off the hook. In fact, the company might even have a rule forbidding use of company facilities for personal use--that would be a clincher of some sort. But what do I know--perhaps a patent attorney here has better info. -- David Sternlight PGP public key on request; RIPEM public key on server =-=-=-=-=-= From: twillis@pintu.demon.co.uk (Tom Willis) Subject: PGP vs. RIPEM Date: Thu, 26 Nov 1992 15:35:35 +0000 In article hmiller@lucpul.it.luc.edu writes: > I'm forwarding the following for Zhahai Stewart: > >Date: Mon, 23 Nov 92 17:14:36 PDT >From: Zhahai.Stewart@f93.n104.z1.FIDONET.ORG (Zhahai Stewart) >Subject: Some conceptual differences: PGP/PEM > > There seems to be some discussion regarding the relative merits of > RIPEM and PGP; perhaps it would be worthwhile to explain why the two > have different niches, and neither is likely to fill the other's niche > well. > > RIPEM is compliant with the PEM standard (draft RFC). Its whole > purpose in life is enhancing Internet email. The PEM standard is > designed to be highly integrated into the Internet; this means that > it is relatively more limited, and by being so limited it can do a > good job at the one task it takes on. > > PGP is a very portable privacy system with many more features and a > much broader scope. It could be used with many different forms of > email, as well as for totally non mail oriented applications. As > such, it does not integrate as well with Internet mail. [--- parts deleted ---] > Consider that one could correspond securely for years with some "entity" > (generally another human being) without ever knowing "who" they were. > What you do know is that the same "entity" read and wrote those many > messages you have exchanged; nobody else can pretend to be them (or > you), and nobody else can eavestap on your interchanges. Their public > key is in effect an unforgeable "handle" by which you know them. Over > the years,you might use various mailboxes, usernames, networks, and > even different media, yet you know it's still the same person. This > is as solid a thread of "identity continuity" as you can get in the > electronic world, and so it forms the basis of the concept of > "identity" for PGP. I agree with this distinction; unfortunately, it can be seen as `the key is the person', which I don't think is the intent of the article. It _is_ important IMHO to see that a key known to belong to a particular correspondent (whatever name or mailbox they currently adopt) is a key that I should be happy to use to correspond with the other party. And, if I wish to `introduce' said other party to a friend/colleague, the key is a far better handle than a mailbox, postal address or even name. However, what implications does this have for certification? What does certifying a key/ID pair mean in this context? If I sign the key/ID pair what am I saying? In the context of `handle', it is irrelevant whether or not I have met the key owner, but it could be that the owner is using an alias and signing the key/name pair would not be true. I have argued, and been persuaded against, saying that signing a key/ID pair means that I am confident that the key and the (e.g. mailbox) ID belong together. But the mailbox ID probably includes a personal name (and I have no means of certifying _that_ association without a lot more knowledge) - and the mailbox could have been broken and diverted for years! I believe that certifying an ID is a problem - more so in the case of PGP than for the more limited aims of a PEM system. > > We don't like to refer to each other by 1000 bit numbers, tho, so PGP > allows you to associate a key with a textual "userid". This could be > a full legal name as it appears on a passport. It could be a nickname > or "handle". It could be a login or user name on a given system > (including an Internet mailbox address). It could be all the > information on your drivers license, complete with number. It could > be your postal address. The point is that the "identity" core is the > key itself, and each userid is an independent secondary association > with the key. And you can have many such secondary associations (for > example, one or more of each of the above), each used in different > contexts. Use the drivers license one to prove your age, assuming > it is signed as visually verified by someone that the recipient trusts; > use whichever email address is appropriate for the network on which > you are communicating; etc. They can also vary over time; addresses > change, drivers license numbers change, even names change, especially > with marriage. Yet your identity remains the same; whoever possesses > the secret key "is" the entity associated with it. This argues strongly for multiple IDs to any key - and again I agree. Most of us have various mailboxes, and one mailbox can have different semantics on different mail systems (e.g. a FIDONET mailbox). We also have different roles: most of us would expect to receive mail by post, perhaps by internal company mail, and associating these `ID's with a key could be important. I might wish to conceal some of my IDs from most people (and actually, PGP does not make this easy) - perhaps I have a regular alias for anonymous postings, or I am the Postmaster of our mail machine: revealing these would most of the time not be useful to me. I also agree strongly that it is _important_ which ID to use when signing someone else's key/ID, or when signing a document for transmission; signing with my postal address ID is not likely to be very acceptable to any paranoid e-mail recipient! One thing that PGP does not give (in the current implementations) is a testimony text: for example, I might wish to sign someone's key/license association stating that I have "formally inspected their driver's license and agree that it belongs to the given keyholder" (or the weaker "I saw the license, and it looks OK"). Similarly, I could wish to say "I am pretty sure this key and the named mail box belong together" as distinct from "I set up this mailbox, gave the password to _this_ person, and so I am positive that they belong together". Different strengths, but only the one mechanism. I note that the internals document has identified types {generic, persona, casual, positive ID} and reserved codes for them in the future. I reckon that about meets this concern! Maybe I am missing a point? For any real-life signature, we place trust in it according to (a) whether or not we know the originator, (b) whether or not we trust the originator, and (c) how hard they will have tried to be _right_ this time. PGP caters for the first two, not the third. For example, I try to be pretty damn sure about signing cheques (OK - I'm a Brit), but I might even not _read_ some of the letters placed in front of me to sign. > Of course, the linkage or association of a key with a given userid > string is only as meaningful as the signatures on that association. > For a nickname, a self-signature is sufficient (if the keyholder signed > it themselves, then you at least know "that's what they call themselves"). > In general, you should always look for a self-signature, perhaps in > addition to others, depending on context. For a legal name, as with > a contract, a stronger outside signature may be needed; that is, the > key to userid association should be signed by someone or some > institution YOU know and trust. PGP has pretty powerful key management > to support this type of decentralized trust decision making. Ah! A new concept (to me). Self-signature! I see the point, I think. If I have a resonably accepted key/ID pair (i.e. one signed by a number of people), then I might want to spread the acceptance to some of my aliases (e.g. when I move to a new mail server, or change jobs). I hadn't thought of that. Neat! However, isn't a key/ID pair actually signed with the secret key when attached? I had assumed so, but checking the internals document I see it is NOT. I really don't see why not - it seems to me obvious that only the owner of a key should be able to associate new IDs with it. Again - am I missing something? > Of course, the same person can have multiple keys if they wish; the > choice of tying together various "userid strings" to a single key, or > to separate keys, is up to the individual. If you want a > nom-de-phosphor, with a separate key, you can easily manage that. Solves some of my problems about controlling the disclosure of IDs. > These "userid" strings can be used for many purposes beside email > addresses. Some were given above. Other examples could be certifying > that the given person (whoever owns that key) is an employee of XYZ > Corp., with an expiration date, and signed with the company key. This > person could keep that signed userid on their keychain, and give out > copies only when they wish to prove their association with XYZ corp. > > So PEM's fundamental concept of identity is the volatile one of > "internet mailbox"; and a top down chain of official certification is > used to verify the association between the (primary) mailbox and a > (secondary) key. key/ID == key/MailBox > PGP's fundamental concept of identity is the key > itself (which one may keep for many years), and the association with > one or many email addresses, postal addresses, job associations, > usernames, legal names, passpord or drivers license numbers, etc. key/ID == key/?; what purpose is the ID? As a simple human-readable mnemonic? What then is the meaning of certifying the key/ID pair? Maybe I've confused myself again. > are secondary, multiple, indepenent, extensible, and flexible. This > permits a much wider range of application; individual control of > which "aspects" of one's identity one wishes to disclose (by choosing > which of one's multiple userids, and which signatures thereof, one > gives to each person; and decentralized trust systems. Thanks for the article - it gave me much cause for thought. Tom \/\/illis | 1. twillis@pintu.demon.co.uk | Have PGP 2.0 key ... DGA Ltd | 2. GBR55N55@IBMMAIL | I encrypt therefore I am? LONDON UK | 3. 100042.446@Compuserve.com | ... Encrypto ergo sum? =-=-=-=-=-= Newsgroups: alt.security.pgp From: palmer@Trade_Zone.msfc.nasa.gov (Paul (Cliffy) Palmer) Subject: Re: Is this public or commercial pgp use? Date: Fri, 27 Nov 1992 18:51:35 GMT >Private use of pgp by individuals is apparently allowed. Is private use of pgp really allowed? I know that under U.S. patent law an individual can make a copy of an invention (patented by someone else) for personal use. But I believe that the number of copies is limited (1?). Also, IMHO, I am not sure that the courts would consider the small amount of effort I would perform to install pgp as the act of making the copy (This honor would go to the author(s) I think...) Or am I missing the point and the permission for private use by individuals comes from the magnanimous(?) folks at RSA? =-=-=-=-=-= From: paul@kuhub.cc.ukans.edu Newsgroups: alt.security.pgp,sci.crypt Subject: RIPEM goes international? Date: 29 Nov 92 06:23:44 CST sci.crypt has a posting indicating an rsa.tar.Z is available. If one looks closely there is also available an "export" version of RIPEM, called RPEM, is provided by the author/maintainer of RIPEM. Presumably the RSA and DES (the RSAREF library contents) code have been "stripped" from the RPEM submission. Noteworthy, however, is that versions of RSA and DES software are available on the same ftp site in the same directory. This would seem to make RIPEM available internationally. The remaining question is whether the an implementation of RPEM that interoperates successfully with RIPEM has been done using the code provided at that ftp site. This also implies that all the code necessary to make an encryption compatible PGP is available! =-=-=-=-=-= Newsgroups: alt.security.pgp,sci.crypt From: henderso@netcom.com (Mark Henderson) Subject: Re: RIPEM goes international? Date: Sun, 29 Nov 1992 19:09:51 GMT In article <1992Nov29.062344.45187@kuhub.cc.ukans.edu> paul@kuhub.cc.ukans.edu writes: >sci.crypt has a posting indicating an rsa.tar.Z is available. If one >looks closely there is also available an "export" version of RIPEM, >called RPEM, is provided by the author/maintainer of RIPEM. RPEM is a program which uses Rabin encryption in conjunction with DES/NEWDES. It was released about a year ago. It does have some code in common with RIPEM, but it is certainly not an export version of RIPEM. There is a longer story about RPEM involving some nasty business with PKP, which I won't go into now. >This would seem to make RIPEM available internationally. The remaining >question is whether the an implementation of RPEM that interoperates >successfully with RIPEM has been done using the code provided at that >ftp site. Well, I suppose you could use the code available at ghost as a starting point for writing a program which would interoperate with RIPEM, but that would take considerable time and effort. Mark =-=-=-=-=-= From: snark@blegga.u.washington.edu (David Howell) Newsgroups: alt.security.pgp Subject: Amiga bug Date: 29 Nov 92 20:14:59 GMT I'm fighting a persistent bug in the path handling of the Amiga version of PGP 2.0. The environment variable PGPPATH is set to work:tools/text/crypto but I often (but not always) get errors like the following: Cannot open configuration file work:tools/text/crypto1F xF/config.txt I don't know exactly what you're going to see in this message, but between the word "crypto" and the slash before the word "config" are the characters 31 C6 20 F8 C6 (in hex). Other characters have appeared in that space. It doesn't seem to have any problem using the environment variable to find the public ring file, but the config and secring files generally fail. Not always, though. Re-running sometimes solves the problem. =-=-=-=-=-= Newsgroups: alt.security.pgp From: ray@rgm.com (Ray Mendonsa) Subject: pgp for K&R C Date: Mon, 30 Nov 1992 08:19:20 GMT I'm curious about PGP, but the sources I grabbed were all ANSI C. I have a more primitive K&R compiler on my system. Is there any hope? Thanks. -- Ray Mendonsa ----- ray@rgm.com ---- Admin., rgm.com ---------> 916/923-5013 8n1,HST -- login: new -- Public access Usenet --> Oh yes. . . It WILL be mine. =-=-=-=-=-= Newsgroups: alt.security.pgp From: mch@sqwest.wimsey.bc.ca (Mark C. Henderson) Subject: Re: pgp for K&R C Organization: SoftQuad Inc., Surrey B.C. CANADA Date: Tue, 1 Dec 1992 23:04:38 GMT In article <9211300019.03@rgm.com> ray@rgm.com (Ray Mendonsa) writes: > >I'm curious about PGP, but the sources I grabbed were all ANSI C. I >have a more primitive K&R compiler on my system. Is there any hope? > >Thanks. >-- >Ray Mendonsa ----- ray@rgm.com ---- Admin., rgm.com ---------> >916/923-5013 8n1,HST -- login: new -- Public access Usenet --> >Oh yes. . . It WILL be mine. Get unproto. You'll find it at your favourite comp.sources.misc archive site. Works nicely. It will even translate (void *) to char * and such if you're compiler needs it. Posting-number: Volume 27, Issue 85 Archive-name: unproto/part01 Posting-number: Volume 27, Issue 86 Archive-name: unproto/part02 Posting-number: Volume 28, Issue 69 Archive-name: unproto/patch01 Mark -- Mark Henderson, SoftQuad Inc, 108-10070 King George Hwy, Surrey, B.C. V3T 2W4 Internet: markh@wimsey.bc.ca, mch@sqwest.wimsey.bc.ca, mch@holonet.net UUCP: {van-bc,sq}!sqwest!mch Telephone: +1 604 585 8394 Fax: +1 604 585 1926 RIPEM public key available by Email/finger mch@holonet.net/keyserver =-=-=-=-=-= From: mpollard@denver.cba.du.edu (Max Pollard) Newsgroups: alt.security.pgp Subject: NeXT support Date: 1 Dec 92 17:25:48 GMT I have tried to get PGP 2.0 to compile on the Next, and due to my unfamiliarity with it I have been unsuccessful. I was wondering if anyone has compiled PGP2.0 to run on the Next, or better yet has setup an interface for NeXTStep. If nobody has done so, might I suggest that it be made available through the services menu. Please E-Mail me if you know where I might be able to FTP what I am looking for. Max Pollard ! They say there is gold ! mpollard@denver.cba.du.edu ! and I'm looking for thrills ! Q. Image & Advertising ! - Pink Floyd ! =-=-=-=-=-= Newsgroups: alt.security.pgp From: gtf1000@cus.cam.ac.uk (G.T. Falk) Subject: Re: NeXT support Date: Wed, 2 Dec 1992 14:28:31 GMT Here's a Makefile to get pgp2.0 to compile on a NeXT. You'll have to add a semicolon to one line in fileio.c as well (your compiler will tell you where.) g. ------------------------- # makefile for PGP (unix) # # CFLAGS options: # -DHIGHFIRST if building PGP on a big-endian system # -DMPORTABLE if there is no assembly version of the mp_smul function # -DDEBUG to include debugging information # -Dfopen=myfopen # if your fopen() doesn't like 'b' as the mode modifier # -DNOTERMIO if your system has no termios # -DDYN_ALLOC if your compiler does not support large static arrays # -DSMALL_MEM if your machine has a small memory (required for MSDOS) # For portability to small systems, WSIZE must not be set above 8192. # Define one of: # -DUNIT32 to use 32 bit units (use only with asm primitives) # -DPORTABLE to build the portable version of the RSA primitives # (ie if no optimized asm versions are available) # The above two defines are incompatible. # Define one of: # -DMERRITT Merritt's modmult (fast on risc machines) # -DPEASANT Russian peasant modulo multiply algorithm # -DUPTON default: use Upton's modmult algorithm */ # Define one of: # -DUSE_SELECT to use select() system call # -DUSE_NBIO to use non-blocking read() # To define the OS we are compiling under, define one of: # -DMSDOS, -DUNIX, -DVMS, -DATARI, -DAMIGA CFLAGS= -O -DUNIX -DMPORTABLE -DPORTABLE $(BYTEORDER) # must set byte order for targets "sysv" and "bsd" # BYTEORDER= -DHIGHFIRST CC = cc LD = cc # Link command LDFLAGS = # Flags for linker CPP = $(CC) -E MAKE = make ASM = $(CC) # Assembler command ASMFLAGS = -c # Flags for assembler OBJS_EXT= # ASM obj. files LIBS_EXT= # Libararies PROJ =pgp default: @echo "type:" @echo " \"make sunspc\" for Sun with spc compiler" @echo " \"make sungcc\" for Sun with GNU gcc" @echo " \"make suncc\" for Sun with cc and unproto (first get unproto, unpack" @echo " in subdirectory 'unproto')" @echo " \"make next\" for NeXT" @echo " \"make sysv\" for SVR4" @echo " \"make hpux\" for HPUX" @echo " \"make sysv_386\" for SVR4 386 with asm primitives" @echo " \"make x286\" for XENIX/286 with asm primitives and unproto" @echo " \"make ultrix\" for DEC 4.2BSD Ultrix" @echo " \"make rs6000\" for RS6000 AIX" all: $(PROJ) 80386.o: 80386.S $(CPP) 80386.S > 80386.s $(ASM) $(ASMFLAGS) 80386.s rm -f 80386.s 8086.o: 8086.asm cp 8086.asm 8086.s $(ASM) $(ASMFLAGS) 8086.s rm -f 8086.s ZIPOBJS= zbits.o zdeflate.o zfile_io.o zglobals.o \ zinflate.o zip.o zipup.o ztrees.o zunzip.o OBJ1 = pgp.o crypto.o keymgmt.o fileio.o \ mdfile.o more.o armor.o mpilib.o mpiio.o \ genprime.o rsagen.o random.o idea.o passwd.o \ md5.o system.o language.o getopt.o keyadd.o \ config.o keymaint.o charset.o OBJS = $(OBJ1) $(ZIPOBJS) $(OBJS_EXT) $(PROJ): $(OBJS) $(LD) $(OBJS) -o $(PROJ) $(LDFLAGS) $(LIBS_EXT) linux: $(MAKE) all CC=gcc LD=gcc OBJS_EXT=80386.o \ CFLAGS="-O -DUNIX -DUNIT32" sunspc: $(MAKE) all CC="ccspc -B/1.8.6/sun4 -ansi -w -I/usr/include" \ CFLAGS="-O -DUNIX -DHIGHFIRST -DUNIT32 -DMERRITT" \ OBJS_EXT=sparc.o # Sun with gcc sungcc: $(MAKE) all CC=gcc LD=gcc OBJS_EXT=sparc.o \ CFLAGS="-O -DUNIX -DHIGHFIRST -DUNIT32 -DMERRITT" \ # Sun with standard cc: compile with unproto suncc: unproto/cpp $(MAKE) all CC=cc LD=cc OBJS_EXT=sparc.o \ CFLAGS="-Qpath unproto -O -DUNIX -DHIGHFIRST -DUNIT32 -DMERRITT" next: $(MAKE) all CC=cc LD=cc \ CFLAGS="-O -DUNIX -DHIGHFIRST -DPORTABLE -DMPORTABLE \ -DMERRITT -DNOTERMIO" sysv: $(MAKE) all CPP=/usr/lib/cpp \ CFLAGS="-O -DUNIX -DPORTABLE -DMPORTABLE -DUSE_NBIO $(BYTEORDER)" hpux: $(MAKE) all CPP=/usr/lib/cpp \ CFLAGS="+DA1.0 -Aa +O3 Obb5000 \ -D_INCLUDE_POSIX_SOURCE -D_INCLUDE_HPUX_SOURCE \ -D_INCLUDE_XOPEN_SOURCE \ -DHIGHFIRST -DUNIX -DMPORTABLE -DPORTABLE \ -DMERRITT -DUSE_NBIO -DWSIZE=8192" # optimized version with 80386.S sysv_386: $(MAKE) all CPP=/usr/lib/cpp OBJS_EXT=80386.o \ CFLAGS="-O -DUNIX -DUNIT32 -DUSE_NBIO" # Xenix 286 x286: $(MAKE) all CC="ccc.x286 -M2l" LD="cc -M2l" ASM="cc -M2l" \ OBJS_EXT=8086.o LDFLAGS="-F 3000" \ CFLAGS="-LARGE -Ot -DUNIX -DNOPROTO -DSMALL_MEM -DDYN_ALLOC \ -DUSE_NBIO -Dstrstr=mystrstr" # DEC Ultrix 4.2 BSD with gcc # -DSIG_DFL=0 may be necessary because of gcc header problem ultrix: $(MAKE) all CC=gcc LD=gcc \ CFLAGS="-O -DUNIX -DPORTABLE -DMPORTABLE -DUSE_SELECT -DSIG_DFL=0" rs6000: $(MAKE) all CFLAGS="-O -DUNIX -DPORTABLE -DMPORTABLE -DUSE_NBIO \ -DHIGHFIRST -DMERRITT" bsd_old: unproto/unproto $(MAKE) all CC=./ccc LD=cc \ CFLAGS="-O -DUNIX -DPORTABLE -DMPORTABLE $(BYTEORDER) -DBSD_OLD \ -I. -DNOTERMIO -Dstrstr=mystrstr" # # unproto for K&R compilers # # unproto was posted on comp.sources.misc: v23i012 v23i013 # # unpack the unproto package in subdirectory unproto # # unproto: needs preprocessed input unproto/unproto:: cd unproto ; $(MAKE) PROG=unproto PIPE= # cpp: pipes through /lib/cpp unproto/cpp:: cd unproto ; $(MAKE) clean: -rm -f *.o $(PROJ) core a.out tags tags: ctags *.c *.h ## Dependencies ## config.o : config.c usuals.h pgp.h crypto.o : crypto.c mpilib.h usuals.h mpiio.h random.h idea.h crypto.h \ keymgmt.h mdfile.h md5.h fileio.h language.h pgp.h fileio.o : fileio.c random.h usuals.h mpilib.h mpiio.h fileio.h language.h \ pgp.h genprime.o : genprime.c mpilib.h usuals.h genprime.h random.h getopt.o : getopt.c idea.o : idea.c idea.h usuals.h keyadd.o : keyadd.c mpilib.h usuals.h idea.h random.h crypto.h fileio.h \ keymgmt.h genprime.h rsagen.h mpiio.h language.h pgp.h keymaint.o : keymaint.c mpilib.h usuals.h random.h crypto.h fileio.h \ keymgmt.h mpiio.h language.h pgp.h keymgmt.o : keymgmt.c mpilib.h usuals.h idea.h random.h crypto.h fileio.h \ keymgmt.h genprime.h rsagen.h mpiio.h language.h pgp.h language.o : language.c language.h mdfile.o : mdfile.c mpilib.h usuals.h mdfile.h md5.h language.h pgp.h md5.o : md5.c md5.h more.o : more.c mpilib.h usuals.h language.h fileio.h pgp.h mpiio.o : mpiio.c mpilib.h usuals.h mpiio.h pgp.h mpilib.o : mpilib.c mpilib.h usuals.h passwd.o : passwd.c random.h usuals.h md5.h language.h pgp.h armor.o : armor.c mpilib.h usuals.h fileio.h mpiio.h language.h pgp.h pgp.o : pgp.c mpilib.h usuals.h random.h crypto.h fileio.h keymgmt.h \ language.h pgp.h random.o : random.c random.h usuals.h language.h rsagen.o : rsagen.c mpilib.h usuals.h genprime.h rsagen.h random.h system.o : system.c ## zbits.o : zbits.c zip.h ztailor.h ziperr.h zdeflate.o : zdeflate.c zip.h ztailor.h ziperr.h zfile_io.o : zfile_io.c zunzip.h zglobals.o : zglobals.c zip.h ztailor.h ziperr.h zinflate.o : zinflate.c zunzip.h zip.o : zip.c usuals.h fileio.h language.h pgp.h zipup.o : zipup.c zip.h ztailor.h ziperr.h zrevisio.h ztrees.o : ztrees.c zip.h ztailor.h ziperr.h zunzip.o : zunzip.c zunzip.h =-=-=-=-=-= Newsgroups: alt.security.pgp From: gtf1000@cus.cam.ac.uk (G.T. Falk) Subject: Re: NeXT support Date: Wed, 2 Dec 1992 14:38:13 GMT With regards to my previous posting (of the Makefile): "make" requires the indented lines to start with a tab character. If you paste from a terminal window, these may have been converted to spaces and you'll have to convert them back again. g. Finger me for my pgp key and related information. gtf1000@cus.cam.ac.uk =-=-=-=-=-= Newsgroups: alt.security.pgp From: sowa@netcom.com (Erik Sowa) Subject: Re: NeXT support Date: Wed, 2 Dec 1992 19:09:30 GMT >>>>> "Max" == Max Pollard writes: Max> I have tried to get PGP 2.0 to compile on the Next, and due to my Max> unfamiliarity with it I have been unsuccessful. >From my notefile: The 2.0 source has a couple of NeXT-related ifdefs scattered about, but no entry in the Makefile. I cobbled together one that works. There seems to be a missing semicolon in fileio.c (the real reason for this note) that few architectures would see. The NeXT (and perhaps Amiga) does, though! The line in fileio.c is: namemax = MAX_NAMELEN fileio.c compiles if and only if a semicolon is added. The appropriate addition to makefile.unx is: # NeXT - note problem in distributed fileio.c -- missing semicolon line 263 next: $(MAKE) all \ CFLAGS="-O -DNeXT -DUNIX -DHIGHFIRST -DPORTABLE -DMPORTABLE -DNOTERMIO" Hope this helps! -- Erik Sowa (sowa@netcom.com) =-=-=-=-=-= From: emv@msen.com (Edward Vielmetti) Newsgroups: alt.security.pgp Subject: PGP for 386BSD or BSDI ? Date: 3 Dec 1992 02:42:43 GMT Hi. Has anyone done the port? I don't see it on either of the lists of ported software, but that may simply be an oversight. Edward Vielmetti, vice president for research, Msen Inc. emv@Msen.com Msen Inc., 628 Brooks, Ann Arbor MI 48103 +1 313 998 GLOB =-=-=-=-=-= Newsgroups: alt.security.pgp From: don@eecs.umich.edu (Don Winsor) Subject: Re: PGP for 386BSD or BSDI ? Date: Thu, 3 Dec 1992 14:14:44 GMT It's easy to build for 386BSD. The only big problem is the busted toupper/tolower routines; if you configure appropriately and compile in good versions of these routines everything seems to work file. To build PGP for 386BSD: 1) Unpack the distribution (unix_pgp20.tar.Z) 2) Go into the "pgp-2.0/src" directory. 3) Apply the patches supplied at the end of this article: * Makefile change to include a fixed "isctype" * Makefile support for a 386bsd configuration * A small configuration fix for fileio.c * A working "isctype.c" file 4) Run "make 386bsd" Standard disclaimers: absolutely no warranty, use at own risk, copyright/patent status not verified, buyer beware, may be habit forming, etc. -- Don Winsor -- Department of Electrical Engineering and Computer Science -- The University of Michigan -- Ann Arbor, Michigan 48109-2122 -- don@eecs.umich.edu ================ pgp-2.0 patches for 386bsd follow ================ *** Makefile~ Thu Sep 10 08:25:40 1992 --- Makefile Thu Oct 22 13:22:38 1992 *************** *** 83,89 **** mdfile.o more.o armor.o mpilib.o mpiio.o \ genprime.o rsagen.o random.o idea.o passwd.o \ md5.o system.o language.o getopt.o keyadd.o \ ! config.o keymaint.o charset.o OBJS = $(OBJ1) $(ZIPOBJS) $(OBJS_EXT) --- 83,89 ---- mdfile.o more.o armor.o mpilib.o mpiio.o \ genprime.o rsagen.o random.o idea.o passwd.o \ md5.o system.o language.o getopt.o keyadd.o \ ! config.o keymaint.o charset.o isctype.o OBJS = $(OBJ1) $(ZIPOBJS) $(OBJS_EXT) *************** *** 92,97 **** --- 92,101 ---- linux: + $(MAKE) all CC=gcc LD=gcc OBJS_EXT=80386.o \ + CFLAGS="-O -DUNIX -DUNIT32" + + 386bsd: $(MAKE) all CC=gcc LD=gcc OBJS_EXT=80386.o \ CFLAGS="-O -DUNIX -DUNIT32" *** fileio.c~ Sun Aug 30 23:02:46 1992 --- fileio.c Fri Oct 9 06:30:26 1992 *************** *** 253,258 **** --- 253,259 ---- #endif #endif + #undef UNIX void truncate_name(char *path, int ext_len) { /* truncate the filename so that an extension can be tacked on. */ #ifdef UNIX /* for other systems this is a no-op */ *** isctype.c~ Thu Dec 3 08:29:54 1992 --- isctype.c Thu Oct 22 13:22:12 1992 *************** *** 0 **** --- 1,139 ---- + /* + * Copyright (c) 1989 The Regents of the University of California. + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by the University of + * California, Berkeley and its contributors. + * 4. Neither the name of the University nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * PATCHES MAGIC LEVEL PATCH THAT GOT US HERE + * -------------------- ----- ---------------------- + * CURRENT PATCH LEVEL: 1 00027 + * -------------------- ----- ---------------------- + * + * 02 Aug 92 Wiljo Heinen Fixed toupper()/tolower() range check + */ + + #if defined(LIBC_SCCS) && !defined(lint) + static char sccsid[] = "@(#)isctype.c 5.2 (Berkeley) 6/1/90"; + #endif /* LIBC_SCCS and not lint */ + + #define _ANSI_LIBRARY + #include + + #undef isalnum + isalnum(c) + int c; + { + return((_ctype_ + 1)[c] & (_U|_L|_N)); + } + + #undef isalpha + isalpha(c) + int c; + { + return((_ctype_ + 1)[c] & (_U|_L)); + } + + #undef iscntrl + iscntrl(c) + int c; + { + return((_ctype_ + 1)[c] & _C); + } + + #undef isdigit + isdigit(c) + int c; + { + return((_ctype_ + 1)[c] & _N); + } + + #undef isgraph + isgraph(c) + int c; + { + return((_ctype_ + 1)[c] & (_P|_U|_L|_N)); + } + + #undef islower + islower(c) + int c; + { + return((_ctype_ + 1)[c] & _L); + } + + #undef isprint + isprint(c) + int c; + { + return((_ctype_ + 1)[c] & (_P|_U|_L|_N|_B)); + } + + #undef ispunct + ispunct(c) + int c; + { + return((_ctype_ + 1)[c] & _P); + } + + #undef isspace + isspace(c) + int c; + { + return((_ctype_ + 1)[c] & _S); + } + + #undef isupper + isupper(c) + int c; + { + return((_ctype_ + 1)[c] & _U); + } + + #undef isxdigit + isxdigit(c) + int c; + { + return((_ctype_ + 1)[c] & (_N|_X)); + } + + #undef tolower + tolower(c) + int c; + { + /* was: return((c) - 'A' + 'a');*/ + return ( isupper(c) ? c - 'A' + 'a' : c); + } + + #undef toupper + toupper(c) + int c; + { + /* was: return((c) - 'a' + 'A');*/ + return ( islower(c) ? c - 'a' + 'A' : c); + } -- -- Donald Winsor -- don@eecs.umich.edu ***** End Info-PGP Digest ***** From hmiller@lucpul.it.luc.edu Wed Dec 9 01:09:37 1992 Return-Path: Received: from nkosi.well.sf.ca.us by well.sf.ca.us with SMTP (5.65c/SMI-4.1/well-921206-1) id AA28581; Wed, 9 Dec 1992 01:09:27 -0800 Received: from lucpul.it.luc.edu by nkosi.well.sf.ca.us (5.65c/SMI-4.1/nkosi-921112-1) id AA18788; Wed, 9 Dec 1992 01:09:23 -0800 Received: by lucpul.it.luc.edu (5.57/Ultrix3.0-C) id AA03612; Wed, 9 Dec 92 03:11:50 -0600 Message-Id: <9212090911.AA03612@lucpul.it.luc.edu> Subject: Info-PGP v. 1 # 36 From: hmiller@lucpul.it.luc.edu Date: Wed, 9 Dec 92 3:11:50 CST Reply-To: info-pgp-request@lucpul.it.luc.edu To: aissecur@well.sf.ca.us X-Mailer: fastmail [version 2.3 PL11] Info-PGP: PGP Digest Tuesday 8 December 1992 Volume 1 : Number 36 Hugh Miller, List Manager / Moderator Info-PGP is a digested mailing list dedicated to discussion of Philip Zimmermann's `Pretty Good Privacy' (PGP) public-key encryption program for MS-DOS, Unix, VMS, Atari, Amiga, SPARC, Macintosh, and (hopefully) other operating systems. It is primarily intended for users on Internet sites without access to the `alt.security.pgp' newsgroup. Most submissions to alt.security.pgp will be saved to Info-PGP, as well as occasional relevant articles from sci.crypt or other newsgroups. Info-PGP will also contain mailings directed to the list address. To SUBSCRIBE to Info-PGP, please send a (polite) note to info-pgp-request@lucpul.it.luc.edu. This is not a mailserver; there is a human being on the other end, and bodiless messages with "Subject:" lines reading "SUBSCRIBE INFO-PGP" will be ignored until the sender develops manners. To SUBMIT material for posting to Info-PGP, please mail to info-pgp@lucpul.it.luc.edu. In both cases, PLEASE include your name and Internet "From:" address. Submissions will be posted pretty well as received, although the list maintainer / moderator reserves the right to omit redundant messages, trim bloated headers & .sigs, and other such minor piffle. I will not be able to acknowledge submissions, nor, I regret, will I be able to pass posts on to alt.security.pgp for those whose sites lack access. Due to U.S. export restrictions on cryptographic software, I regret that I cannot include postings containing actual source code (or compiled binaries) of same. For the time being at least I am including patches under the same ukase. I regret having to do this, but the law, howbeit unjust, is the law. If a European reader would like to handle that end of things, perhaps run a "Info-PGP-Code" digest or somesuch, maybe this little problem could be worked around. I have received a promise of some space on an anonymous-ftp'able Internet site for back issues of Info-PGP Digest. Full details as soon as they firm up. Oh, yes: ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; STANDARD DISCLAIMERS APPLY. Hugh Miller | Asst. Prof. of Philosophy | Loyola University Chicago FAX: 312-508-2292 | Voice: 312-508-2727 | hmiller@lucpul.it.luc.edu Signed PGP v.2.1 public key certificate available by e-mail & finger(1) ------------------------------------------------------------------------------- From: dswartz@redondo.sw.stratus.com (Dan Swartzendruber) Newsgroups: alt.security.pgp Subject: pgp 2.0 fails on Sparc Date: 4 Dec 92 19:29:59 GMT Problems with pgp 2.0 on a Sparc. After typing in the random character sequence, pgp aborts with the error message: Keygen failed! Keygen error. Turning on -DDEBUG in the Makefile didn't help, as none of the various z*.c files would compile. I used the sungcc target... Any ideas? Dan S. =-=-=-=-=-= From: dswartz@sw.stratus.com (Dan Swartzendruber) Newsgroups: alt.security.pgp Subject: Sparc problems... Date: 4 Dec 92 20:04:57 GMT I tried tweaking various Makefile options and discovered that when I change -DUNIT32 to -DPORTABLE, it works. Hmmmmm... Dan S. =-=-=-=-=-= From: honey@citi.umich.edu (Peter Honeyman) Newsgroups: alt.security.pgp Subject: Re: Sparc problems... Date: 4 Dec 1992 23:25:16 GMT Distribution: world similarly, don't use -DMERRITT with rs6000. -DUPTON (the default) seems to work ok. peter =-=-=-=-=-= Newsgroups: alt.security.pgp From: gtoal@pizzabox.demon.co.uk (Graham Toal) Subject: Re: PGP for 386BSD or BSDI ? Date: Fri, 4 Dec 1992 23:51:44 +0000 :It's easy to build for 386BSD. The only big problem is the busted :toupper/tolower routines; if you configure appropriately and compile :in good versions of these routines everything seems to work file. True. And for the lazy among us, I've put a version in rachel.ibmpcug.co.uk:/usr/local/src/pgp20 - sources and binaries. (Not your patches Donald - did the same thing myself a couple of weeks ago...) G =-=-=-=-=-= Newsgroups: sci.crypt,alt.security,alt.security.pgp From: alexb@minerva1.bull.it (Alessandro Bottonelli) Subject: Questions about US/Canadian Laws about public encryption Date: Sat, 5 Dec 1992 15:39:54 GMT I have been following the security related groups for a while trying to understand all the discussion going on about the Legality of Crypto Tecniques, and I haven't been able to understand the following: (1) Is feeding public data or telephone networks with crypted data illegal or those who posted articles on the subject were just wishing it were made illegal ??? (2) Is it illegal to crypt any form of communication (like regular mail) or, as above, people are just wishing it were ? (3) Are there any signs that legislators are going or will regulate the subject in the near or mid-term future. All the above questions are for the USA and Canada. On my part I did read carefully my contract with the Italian Phone COmpany and I haven't been able to find any clause specifying I cannot crypt my voice or data ... Post or e-mail your replies ... -- == Alex Bottonelli / Bull Italia BSP | FAX : +39-(0)2-6779/8463 == == I.S./W.S./Network Security Officer | PHONE: +39-(0)2-6779/8324 == == E-MAIL: A.Bottonelli@it12.bull.it | (BullCom users dial 260+extension) == == BULLTX: /BULLX/IT12X/BOTTONELLI A. | == =-=-=-=-=-= Newsgroups: sci.crypt,alt.security,alt.security.pgp From: David Banisar Subject: Re: Questions about US/Canadian Laws about public encryption Date: Sat, 5 Dec 1992 18:41:08 GMT In article Alessandro Bottonelli, alexb@minerva1.bull.it writes: >I have been following the security related groups for a while trying >to understand all the discussion going on about the Legality of >Crypto Tecniques, and I haven't been able to understand the following: > > (1) Is feeding public data or telephone networks with crypted data > illegal or those who posted articles on the subject were just > wishing it were made illegal ??? > > (2) Is it illegal to crypt any form of communication (like regular > mail) or, as above, people are just wishing it were ? > > (3) Are there any signs that legislators are going or will regulate > the subject in the near or mid-term future. > >All the above questions are for the USA and Canada. On my part I did read >carefully my contract with the Italian Phone COmpany and I haven't >been able to find any clause specifying I cannot crypt my voice or data ... > >Post or e-mail your replies ... In a nutshell, it is not illegal to write, use or distribute encryption software or hardware in the US and Canada subject to copyright and patent law or if the info is classified (ie a NSA encryption program). It is illegal, by regulations (which have the force of law) to export encryption software without prior permission from the Dept. of State (which defers to the National Security Agency on crypto matters). Those regulations are available in the Federeal Register. The law enforcement and intelligence communities have been attempting for years to prevent encryption from becoming widely available. The NSA has threated several inventors over the past 15 years with the patent secrecy act, classifying inventions that use crypto. They have backed off a few times due to bad publicity but may have succeeded many more times that we dont know about. The FBI (or other LE) asked Senator Biden in 1991 to insert a resolution in the Omnibus Crime bill that asked phone companies to prove message traffic to LE in "plaintext" (ie unencrypted) when required by law. The fear was that this provision could have been easily and innocously changed to become enforceable. This provision was removed after many, many people publicly opposed it. The FBI has said numerous times in the last few months that are are working on ways of dealing with encryption and will introduce something in the future about it. They have also publicly stated (Asst. Director Al Bayse in Fed. Computer Week, Nov. 1992) that they will reintroduce the Digital Telephony program in 1993. Dave Banisar CPSR Washington Office =-=-=-=-=-= Newsgroups: sci.crypt,alt.security,alt.security.pgp From: rcain@netcom.com (Robert Cain) Subject: Re: Questions about US/Canadian Laws about public encryption Date: Sat, 5 Dec 1992 22:09:04 GMT alexb@minerva1.bull.it (Alessandro Bottonelli) writes: : I have been following the security related groups for a while trying : to understand all the discussion going on about the Legality of : Crypto Tecniques, and I haven't been able to understand the following: : : (1) Is feeding public data or telephone networks with crypted data : illegal or those who posted articles on the subject were just : wishing it were made illegal ??? Not yet according to specific statute. : : (2) Is it illegal to crypt any form of communication (like regular : mail) or, as above, people are just wishing it were ? Not yet according to specific statute. : : (3) Are there any signs that legislators are going or will regulate : the subject in the near or mid-term future. There was a defeated attempt at a legislative rider that would force communictions carriers that provided encryption services to provide the clear text to LE under court order. Nothing has been introduced, although there has been much speculation, to prevent the marketing of a crypto device for attachment to a phone line. (That would be sorta hard by now if one considers PC's and modems to intrinsically be such devices.) There may be U.S. national security laws broad enough to stop a potential seller of such a device and I have been told that under such laws (of which I know little by definition) a stop order can be issued by a court which you must obey but can't even open because it carries a top secret seal and furthermore you cannot even discuss it without looking at Leavenworth. So it is entirely possible that hidden laws exist to prevent sale of such devices, have been used and we would not know it under the umbrella of U.S. national security. If anyone knows this to be false I would love to be wrong. Conversely if anyone can verify it I would appreciate that. Bob -- Bob Cain rcain@netcom.com 408-358-2007 "There are some strings. They're just not attached." Victoria Roberts PGP 1.0 or 2.0 public key available on request. =-=-=-=-=-= Newsgroups: sci.crypt,alt.security,alt.security.pgp From: karn@servo.qualcomm.com (Phil Karn) Subject: Re: Questions about US/Canadian Laws about public encryption Date: Sun, 6 Dec 1992 08:26:00 GMT In article <1992Dec5.220904.24510@netcom.com> rcain@netcom.com (Robert Cain) writes: >: (3) Are there any signs that legislators are going or will regulate >: the subject in the near or mid-term future. I am unaware of any official proposals to regulate the private use of cryptography within the US. However, several private individuals, notably Dr. Dorothy Denning of Georgetown University, have proposed regulations such as key registration. Given the outcry against both the original S.266 and the FBI Digital Telephony Initiative, these proposals have little realistic chance of becoming law soon. But this is a politically charged topic and substantial vigilance is appropriate. Anyone concerned with protecting their right to privacy through encryption would be well advised to rebut such misguided and dangerous proposals wherever they appear. >There may be U.S. national security >laws broad enough to stop a potential seller of such a device and I >have been told that under such laws (of which I know little by definition) >a stop order can be issued by a court which you must obey but can't even >open because it carries a top secret seal and furthermore you cannot even >discuss it without looking at Leavenworth. So it is entirely possible that >hidden laws exist to prevent sale of such devices, have been used and we >would not know it under the umbrella of U.S. national security. The only US law of which I am aware that could fall into this category is the Invention Secrecy Act of 1951. If you file a patent application on a topic that the government considers to relate to national security, the government has the option of issuing you an "invention secrecy order" that prohibits you from disclosing your invention to anyone who doesn't already know about it. This happened several times in the late 1970s with various communication privacy inventions (Prof. George I Davida of the University of Wisconsin was one such victim). Apparently the law specifies that secrecy orders expire within 1 year unless a "state of national emergency" exists, in which case the secrecy orders continue as long as the emergency. And it wasn't until Sept 1978 that President Carter bothered to end the technical state of emergency invoked by President Truman during the Korean War. (Reference: "The Puzzle Palace" by James Bamford, pp. 445-449.) Yes, this really happened in the United States of America. And you probably thought that only third world military dictatorships used contrived states of emergency to suppress individual civil rights. There is a theory that RSA was deliberately published before patent applications were filed in order to avoid a possible secrecy order. Considering the contemporary secrecy orders and the threats issued at the time by a supposedly "unauthorized" NSA employee against RSA's inventors when they presented their first papers, this was probably a very real concern. So it's possible that they deliberately chose to forego foreign patent protection (since publication immediately waives patent filing rights in all countries but the US) as preferable to having a secrecy order clamped on all uses of RSA. So non-US users enjoy license-free use of RSA thanks to this particular set of quirks in the American legal system. Phil =-=-=-=-=-= From: "Andrew A. Chernov, Black Mage" Newsgroups: comp.unix.bsd,alt.security.pgp Subject: [386bsd] right patch for pgp port Date: Mon, 07 Dec 92 00:44:55 +0300 Hi. Recently I see in news some patch for pgp port to 386bsd. I check it and shure that it is only partial and non-elegant solution. Main problem are that 386bsd's ctype.h incorrect define tolower and toupper. This is not for pgp only but for other programs too, so we need to correct ctype.h instead of pgp in this case. This patch touch: /usr/include/ctype.h (386bsd bug fix) fileio.c makefile.unx Last two file fixes also different with previously posted patch. *** /usr/include/ctype.h.was Sat Feb 29 03:13:14 1992 --- /usr/include/ctype.h Sun Dec 6 23:49:03 1992 *************** *** 59,66 **** #define isgraph(c) ((_ctype_ + 1)[c] & (_P|_U|_L|_N)) #define iscntrl(c) ((_ctype_ + 1)[c] & _C) #define isascii(c) ((unsigned)(c) <= 0177) ! #define toupper(c) ((c) - 'a' + 'A') ! #define tolower(c) ((c) - 'A' + 'a') #define toascii(c) ((c) & 0177) #endif /* !_CTYPE_H_ */ --- 59,68 ---- #define isgraph(c) ((_ctype_ + 1)[c] & (_P|_U|_L|_N)) #define iscntrl(c) ((_ctype_ + 1)[c] & _C) #define isascii(c) ((unsigned)(c) <= 0177) ! #define _toupper(c) ((c) - 'a' + 'A') ! #define _tolower(c) ((c) - 'A' + 'a') ! #define toupper(c) (islower(c) ? _toupper(c) : (c)) ! #define tolower(c) (isupper(c) ? _tolower(c) : (c)) #define toascii(c) ((c) & 0177) #endif /* !_CTYPE_H_ */ *** fileio.c.was Mon Aug 31 05:02:46 1992 --- fileio.c Sun Dec 6 23:59:49 1992 *************** *** 250,257 **** --- 250,261 ---- #ifndef MAX_NAMELEN #if defined(AMIGA) || defined(NeXT) #define MAX_NAMELEN 255 + #else + #ifdef FILENAME_MAX + #define MAX_NAMELEN FILENAME_MAX #endif #endif + #endif void truncate_name(char *path, int ext_len) { /* truncate the filename so that an extension can be tacked on. */ *************** *** 260,266 **** int namemax; #ifdef MAX_NAMELEN /* overrides the use of pathconf() */ ! namemax = MAX_NAMELEN #else #ifdef _PC_NAME_MAX strcpy(dir, path); --- 264,270 ---- int namemax; #ifdef MAX_NAMELEN /* overrides the use of pathconf() */ ! namemax = MAX_NAMELEN; #else #ifdef _PC_NAME_MAX strcpy(dir, path); *** makefile.unx.was Thu Sep 3 00:27:00 1992 --- makefile.unx Mon Dec 7 00:01:52 1992 *************** *** 60,65 **** --- 60,66 ---- @echo " \"make sysv_386\" for SVR4 386 with asm primitives" @echo " \"make x286\" for XENIX/286 with asm primitives and unproto" @echo " \"make ultrix\" for DEC 4.2BSD Ultrix" + @echo " \"make 386bsd\" for Public Domain 386bsd" @echo " \"make rs6000\" for RS6000 AIX" *************** *** 93,98 **** --- 94,103 ---- linux: $(MAKE) all CC=gcc LD=gcc OBJS_EXT=80386.o \ CFLAGS="-O -DUNIX -DUNIT32" + + 386bsd: + $(MAKE) all LDFLAGS=-s OBJS_EXT=80386.o \ + CFLAGS="-pipe -fstrength-reduce -O -DUNIX -DUSE_SELECT -DUNIT32" sunspc: $(MAKE) all CC="ccspc -B/1.8.6/sun4 -ansi -w -I/usr/include" \ -- In-This-Life: Andrew A. Chernov | "Hay mas dicha, mas contento Internet: ache@astral.msk.su | "Que adorar una hermosura Organization: The RELCOM Corp., | "Brujuleada entre los lejos Moscow, Russia | "De lo imposible?!" (Calderon) =-=-=-=-=-= Newsgroups: comp.unix.bsd,alt.security.pgp From: karn@servo.qualcomm.com (Phil Karn) Subject: Re: [386bsd] right patch for pgp port Date: Mon, 7 Dec 1992 06:06:52 GMT PGP also triggers a bug in the fseek() library function that 386BSD inherits from NET-2. Here's the diff to /usr/src/lib/libc/stdio/fseek.c, courtesy of Branko Lankester: *** fseek.c.orig Tue May 7 13:43:56 1991 --- fseek.c Mon Nov 23 23:44:37 1992 *************** *** 215,220 **** --- 215,221 ---- if ((*seekfn)(fp->_cookie, curoff, SEEK_SET) == POS_ERR) goto dumb; fp->_r = 0; + fp->_p = fp->_bf._base; if (HASUB(fp)) FREEUB(fp); fp->_flags &= ~__SEOF; =-=-=-=-=-= From: davidsen@ariel.crd.GE.COM (william E Davidsen) Newsgroups: comp.unix.bsd,alt.security.pgp Subject: Re: [386bsd] right patch for pgp port Date: 7 Dec 92 15:44:59 GMT In article , ache@astral.msk.su (Andrew A. Chernov, Black Mage) writes: | Hi. | Recently I see in news some patch for pgp port to 386bsd. | I check it and shure that it is only partial and non-elegant solution. | Main problem are that 386bsd's ctype.h incorrect define tolower | and toupper. This is not for pgp only but for other programs too, | so we need to correct ctype.h instead of pgp in this case. | ! #define _toupper(c) ((c) - 'a' + 'A') | ! #define _tolower(c) ((c) - 'A' + 'a') | ! #define toupper(c) (islower(c) ? _toupper(c) : (c)) | ! #define tolower(c) (isupper(c) ? _tolower(c) : (c)) The only problem with this code is that existing working code will break, because you evaluate the argument twice. Example: char str[] = "Any string", *sptr = str; int m; for (m=0; m < 4; ++m) myproc(toupper(*(sptr++)); This not only breaks the logic by stepping the pointer twice per character but also returns the wrong values. I would suggest that the only really correct way to do this is by table lookup (don't forget the AND, either). #define toupper(c) _ALLupper[(c) & 0xff] -- bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345 Keyboard controller has been disabled, press F1 to continue. =-=-=-=-=-= Newsgroups: alt.security.pgp Subject: PGP-compatible archiver released From: pgut1@cs.aukuni.ac.nz (Peter Gutmann) Date: Mon, 7 Dec 1992 10:02:43 GMT I just thought I'd mentioned that a PGP-compatible archiver is now available. This uses the same keyrings as PGP, but is an archiver rather than an encryption program. As such it doesn't offer most of the special features of PGP, but does have the following: - Better compression than Arj, Zip, Zoo, etc (based on the Calgary compression corpus, a standard benchmark for compression programs) - PGP-compatible public-key and conventional encryption of archives - *Real* data authentication using digital signatures. - Multi-disk archives (your mileage may vary depending on the OS) - Internationalization support (currently available in four languages, built-in support for multiple character sets). - Quality Postscript documentation (600K worth) - Easy portability to virtually any OS (currently exists for Amiga, Archimedes, Atari ST, Macintosh, MSDOS, OS/2 (16 and 32-bit), and Unix). - Availability of the source code to anyone who wants it. The following versions are available from garbo.uwasa.fi (128.214.87.1): 114243 Nov 20 07:08 garbo.uwasa.fi:/pc/arcers/hpack78.zip 146470 Dec 3 01:01 garbo.uwasa.fi:/pc/doc-soft/hpack78d.zip 511827 Dec 3 14:46 garbo.uwasa.fi:/pc/source/hpack78s.zip 667464 Dec 5 16:43 garbo.uwasa.fi:/unix/arcers/hpack78src.tar.Z where hpack78.zip is the MSDOS executable, hpack78d.zip is the Postscript documentation, hpack78s.zip is the source code, and hpack78src.tar.Z is the source code again but in tar.Z format (note that the latter is a tiny bit more recent that hpack78s.zip and contains changes for the NeXT). There is a (rather primitive) Macintosh executable somewhere on garbo as well, possibly /mac/arcers/hpack78mac.cpt. In order to keep the size of the distribution down, no executables have been provided for the Amiga, Atari ST, and Archimedes versions, but these can be easily created from the source code. There are OS/2 16 and 32-bit executables as well but an archive site for them is still under negotiation (there are obvious problems with placing them on the standard US OS/2 sites :-). Before using HPACK, you should at least read the section of the readme file pertaining to your OS - I could only do so much in terms of testing and cleaning up the different versions, since I often didn't have access to the hardware to try it out on. In particular multidisk archives don't work properly on most systems yet, and won't work until I can get to a machine, or someone else gives me a hand with it (hint hint). There should also be a VMS port, but again I don't have access to the hardware (sigh). Peter. -- pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz (In order of preference - one of 'ems bound to work) =-=-=-=-=-= Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc From: hmiller@lucpul.it.luc.edu (Hugh Miller) Subject: PGP v. 2.1 Released Date: Mon, 7 Dec 1992 20:49:36 GMT -----BEGIN PGP SIGNED MESSAGE----- PGP 2.1 Available - ----------------- Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. This new version of the world's most popular and politically controversial public key encryption program has numerous bug fixes over version 2.0, and several new features. For example, you can now display the MD5 hash of a public key, to facilitate verifying it over the telephone with the owner of that public key. Also, it is now possible to send via email an unencrypted signed message without putting the whole message in Radix-64 format, to make it possible to read without PGP. This is analogous to the PEM MIC-CLEAR signed message functionality. PGP 2.1 incorporates many patches from the user community to port it to more platforms. And it runs faster. Also, a lot of annoying bugs and ergonomic oversights have been fixed. PGP 2.0 fans will find many rough edges have been smoothed out. The filenames are pgp21.zip for the MSDOS executable release, and pgp21src.zip for the source code release. You must have PKUNZIP version 1.1 or later to unzip them, or they won't unzip. The primary initial FTP sites that have it are: Finland: nic.funet.fi (128.214.6.100) Directory: /pub/unix/security/crypt/ Italy: ghost.dsi.unimi.it (149.132.2.1) Directory: /pub/security/ As previously, this prohibited and politically popular program will probably propagate through the same channels as PGP 2.0. Of course, if you live in the USA, you really shouldn't be using it. If you have any questions about where else to get it, contact Hugh Miller, at hmiller@lucpul.it.luc.edu. Hugh can send you the latest evolving list of FTP sites, BBS phone numbers, and other sources. Philip Zimmermann Phil's Pretty Good Software -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyLbAuJ13g7/Z/cLAQFxoAP+OqIqZu2zfA7LycuBJmaF0cms6xyYYok+ ifFW5hIKYUDqvVwLQg5kSXRIUY9fbSXaox6bnww+2YCoEacbzMAAVgTiw8TU7QG0 JryTOHsUIihq9JNBOQ5ONfmHzH0w2gaQ5SGEcJK93typoyvNQMtdtVSeIfkl6ImJ vs/OHzY5LiU= =nV70 -----END PGP SIGNATURE----- -- Hugh Miller | Dept. of Philosophy | Loyola University of Chicago Voice: 312-508-2727 | FAX: 312-508-2292 | hmiller@lucpul.it.luc.edu =-=-=-=-=-= From: ujacampbe@memstvx1.memst.edu (James Campbell) Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc Subject: Re: PGP v. 2.1 Released Date: 8 Dec 92 09:58:51 -0600 >From a cleartext news release signed by Phil Zimmermann (I LOVE the sound of that!): >Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. >This new version of the world's most popular and politically >controversial public key encryption program has numerous bug fixes >over version 2.0, and several new features. Thanks, Mr. Z. This is an _outstanding_ update to an already great piece of software. I've been playing with it since I got it yesterday, and I absolutely _love_ the enhancements. > ...it is now possible to send via email an >unencrypted signed message without putting the whole message in >Radix-64 format, to make it possible to read without PGP. This is >analogous to the PEM MIC-CLEAR signed message functionality. My _favorite_ enhancement! This is something we've all wanted, and its implementation is superb. Just set up a 4DOS alias (or, if you're still using COMMAND.COM, an analgous batch file) that reads pgpc = `pgp -sta +clearsig=on` and 'pgpc filename' will generate a signed cleartext message! This is the PGP we've all been waiting for! > ...PGP 2.0 fans will find many rough edges have been smoothed out. That's the truth! Alas, though, they've even smoothed out the one rough edge with which I scratched my itch for even _better_ security. PGP 2.0 had allowed me to generate public/private key pair with up to 1136 bits; the 2.1 incarnation _draws_the_line_ at 1024 bits ("military grade"). Thankfully, it still accepts my 1136-bit key with grace. So, if you're using a >1024-bit key, or plan to change to one, be sure you keep a copy of your PGP 2.0 executable, to use for generating 1025- to 1136-bit keys after you upgrade to 2.1. >As previously, this prohibited and politically popular program will >probably propagate through the same channels as PGP 2.0. Of course, >if you live in the USA, you really shouldn't be using it. OOPS! Forget everything I said! I was never here! ;-) =========================================================================== James Campbell, Math Sciences Department, MSU; ujacampbe@memstvx1.memst.edu --------------------------------------------------------------------------- =-=-=-=-=-= Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc Subject: Re: PGP v. 2.1 Released From: jsteiner@anwsun.phya.utoledo.edu (jason 'Think!' steiner) Date: 8 Dec 92 15:51:34 EST great program! especially the clearsig and pipe options. one question: how do i set up a vi key to do a cleartext sign? i tried assigning a key to 'pgp -fast +clearsig=on'. this works as a file pipe, but when i try to use it in vi it hangs on asking for my password. i know how to set my password as an environment var, but i'd rather it prompted me each time. jason =-=-=-=-=-= Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc From: strnlght@netcom.com (David Sternlight) Subject: Re: PGP v. 2.1 Released Date: Tue, 8 Dec 1992 17:29:44 GMT I don't understand the comment that "if you're living in the U.S.A. you probably shouldn't be using it" (pgp2.1). I thought it was o.k. for personal, educational, or research use, and only an infringement if used commercially without permission of PKP. Can anyone clear this up once and for all? Thanks; =-=-=-=-=-= From: hmiller (Hugh Miller) Subject: PGP 2.1 Site List To: info-pgp Date: Wed, 9 Dec 92 2:50:32 CST (Last modified: 0820 UTC, 9 Dec 92) PGP v. 2.1 is gradually making its way out into the electronic world. It has been posted to the FidoNet Software Distribution Network and should soon be up on most if not all Canadian and U.S. nodes carrying SDN software. On the Internet, there are many sites to try for anonymous ftp: nic.funet.fi (128.214.6.100) /pub/unix/security/crypt/pgp21.zip (MSDOS binaries + docs) /pub/unix/security/crypt/pgp21src.zip (Source code + docs) /pub/unix/security/crypt/pgp21.tar.Z (Source code in compressed tar format) van-bc.wimsey.bc.ca (192.48.234.1) /pub/crypto/PGP-2.1/pgp21.zip /pub/crypto/PGP-2.1/pgp21src.zip /pub/crypto/PGP-2.1/pgp21.tar.Z ghost.dsi.unimi.it (149.132.2.1) /pub/crypt/pgp21.zip /pub/crypt/pgp21src.zip /pub/crypt/pgp21.tar.Z pencil.cs.missouri.edu (128.206.100.207) /pub/crypt/pgp21.zip /pub/crypt/pgp21src.zip /pub/crypt/pgp21.tar.Z soda.berkeley.edu (128.32.149.19) /pub/cypherpunks/pgp/pgp21.zip /pub/cypherpunks/pgp/pgp21src.zip /pub/cypherpunks/pgp/pgp21.tar.Z eugene.utmb.edu (129.109.9.21) pub/pgp/pgp21.zip pub/pgp/pgp21src.zip pub/pgp/pgp21.tar.Z For those lacking ftp connectivity to the net, nic.funet.fi also offers the files via mail. Send the following mail message to mailserv@nic.funet.fi: ENCODER uuencode SEND pub/unix/security/crypt/pgp21src.zip SEND pub/unix/security/crypt/pgp21.zip This will deposit the two zipfiles, as 15 batched messages, in your mailbox with about 24 hours. Save and uudecode. The Northern Lights BBS in Troy, NY, has both PGP21.ZIP and PGP21SRC.ZIP for free download. Call (518) 237-2163 at 300-2400 bps 8N1 24 hours a day. Then login directly to the pgp account as follows: tnllogin: pgp Password: key and help yourselves. Thanks to Daniel Ray of tnl for this fine service. Another private BBS from which you can obtain PGP for the simple price of the long-distance call time is the Grapevine BBS, the largest BBS in Arkansas. It's run by Jim Wenzel in Little Rock. John Eichler, a PGP user at Grapevine, sent me the following information for your edification and enlightenment: > The GRAPEVINE BBS in Little Rock is the largest BBS in Arkansas. To > help people obtain a copy of PGP21, the GRAPEVINE has set up a special > account for this purpose. The following phone numbers are applicable > and should be dialed in the order presented (i.e., the top one first > since it is the highest speed line). > > (501) 753-6859 > (501) 753-8121 > (501) 791-0124 > (501) 753-4428 > (501) 791-0125 > > When asked to login use the following information. > > name: PGP USER ('PGP' is 1st name, 'USER' is 2nd name) > password: PGP > > There is a special menu which one gets which shows the following > programs to be available. > > PGP21.ZIP = Dos Version of "Pretty Good Privacy" > PGP21SRC.ZIP = Source Code to PGP v2.0 > PGP20OS2.ZIP = OS/2 version of PGP v2.0 > PKZ110.EXE = Current version of DOS based PKzip > > Should you have any questions e-mail either me > (john.eichler@grapevine.lrk.ar.us) or the Sysop of the BBS whose address > is jim.wenzel@grapevine.lrk.ar.us. -- Thanks, John! If none of these sites do it for you, let me know. Film at 11. Best regards! -=- Hugh P.S.: If you come across sites where it's posted -- especially FREE ACCESS sites -- please drop me a line (info-pgp-request@lucpul.it.luc.edu). I'd like to maintain a current list as part of a PGP FAQ list. Thanks to the many correspondents who have helped to contribute to this list on an almost daily basis! Hugh Miller Info-PGP info-pgp-request@lucpul.it.luc.edu ***** End Info-PGP Digest ***** From sbranch Wed Dec 9 09:33:33 1992 Return-Path: Received: by well.sf.ca.us (5.65c/SMI-4.1/well-921206-1) id AA10336; Wed, 9 Dec 1992 09:33:10 -0800 Date: Wed, 9 Dec 1992 09:33:10 -0800 From: Kim Clancy Message-Id: <199212091733.AA10336@well.sf.ca.us> To: aissecur Subject: pgp 1.36 >From hmiller@lucpul.it.luc.edu Wed Dec 9 03:20:33 1992 Return-Path: Received: from nkosi.well.sf.ca.us by well.sf.ca.us with SMTP (5.65c/SMI-4.1/well-921206-1) id AA10401; Wed, 9 Dec 1992 03:20:26 -0800 Received: from lucpul.it.luc.edu by nkosi.well.sf.ca.us (5.65c/SMI-4.1/nkosi-921112-1) id AA00549; Wed, 9 Dec 1992 02:43:25 -0800 Received: by lucpul.it.luc.edu (5.57/Ultrix3.0-C) id AA04389; Wed, 9 Dec 92 04:45:51 -0600 Message-Id: <9212091045.AA04389@lucpul.it.luc.edu> Subject: Info-PGP v. 1 # 36 From: hmiller@lucpul.it.luc.edu Date: Wed, 9 Dec 92 4:45:50 CST Reply-To: info-pgp-request@lucpul.it.luc.edu To: sbranch@well.sf.ca.us X-Mailer: fastmail [version 2.3 PL11] Status: R Info-PGP: PGP Digest Tuesday 8 December 1992 Volume 1 : Number 36 Hugh Miller, List Manager / Moderator Info-PGP is a digested mailing list dedicated to discussion of Philip Zimmermann's `Pretty Good Privacy' (PGP) public-key encryption program for MS-DOS, Unix, VMS, Atari, Amiga, SPARC, Macintosh, and (hopefully) other operating systems. It is primarily intended for users on Internet sites without access to the `alt.security.pgp' newsgroup. Most submissions to alt.security.pgp will be saved to Info-PGP, as well as occasional relevant articles from sci.crypt or other newsgroups. Info-PGP will also contain mailings directed to the list address. To SUBSCRIBE to Info-PGP, please send a (polite) note to info-pgp-request@lucpul.it.luc.edu. This is not a mailserver; there is a human being on the other end, and bodiless messages with "Subject:" lines reading "SUBSCRIBE INFO-PGP" will be ignored until the sender develops manners. To SUBMIT material for posting to Info-PGP, please mail to info-pgp@lucpul.it.luc.edu. In both cases, PLEASE include your name and Internet "From:" address. Submissions will be posted pretty well as received, although the list maintainer / moderator reserves the right to omit redundant messages, trim bloated headers & .sigs, and other such minor piffle. I will not be able to acknowledge submissions, nor, I regret, will I be able to pass posts on to alt.security.pgp for those whose sites lack access. Due to U.S. export restrictions on cryptographic software, I regret that I cannot include postings containing actual source code (or compiled binaries) of same. For the time being at least I am including patches under the same ukase. I regret having to do this, but the law, howbeit unjust, is the law. If a European reader would like to handle that end of things, perhaps run a "Info-PGP-Code" digest or somesuch, maybe this little problem could be worked around. I have received a promise of some space on an anonymous-ftp'able Internet site for back issues of Info-PGP Digest. Full details as soon as they firm up. Oh, yes: ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; STANDARD DISCLAIMERS APPLY. Hugh Miller | Asst. Prof. of Philosophy | Loyola University Chicago FAX: 312-508-2292 | Voice: 312-508-2727 | hmiller@lucpul.it.luc.edu Signed PGP v.2.1 public key certificate available by e-mail & finger(1) ------------------------------------------------------------------------------- From: dswartz@redondo.sw.stratus.com (Dan Swartzendruber) Newsgroups: alt.security.pgp Subject: pgp 2.0 fails on Sparc Date: 4 Dec 92 19:29:59 GMT Problems with pgp 2.0 on a Sparc. After typing in the random character sequence, pgp aborts with the error message: Keygen failed! Keygen error. Turning on -DDEBUG in the Makefile didn't help, as none of the various z*.c files would compile. I used the sungcc target... Any ideas? Dan S. =-=-=-=-=-= From: dswartz@sw.stratus.com (Dan Swartzendruber) Newsgroups: alt.security.pgp Subject: Sparc problems... Date: 4 Dec 92 20:04:57 GMT I tried tweaking various Makefile options and discovered that when I change -DUNIT32 to -DPORTABLE, it works. Hmmmmm... Dan S. =-=-=-=-=-= From: honey@citi.umich.edu (Peter Honeyman) Newsgroups: alt.security.pgp Subject: Re: Sparc problems... Date: 4 Dec 1992 23:25:16 GMT Distribution: world similarly, don't use -DMERRITT with rs6000. -DUPTON (the default) seems to work ok. peter =-=-=-=-=-= Newsgroups: alt.security.pgp From: gtoal@pizzabox.demon.co.uk (Graham Toal) Subject: Re: PGP for 386BSD or BSDI ? Date: Fri, 4 Dec 1992 23:51:44 +0000 :It's easy to build for 386BSD. The only big problem is the busted :toupper/tolower routines; if you configure appropriately and compile :in good versions of these routines everything seems to work file. True. And for the lazy among us, I've put a version in rachel.ibmpcug.co.uk:/usr/local/src/pgp20 - sources and binaries. (Not your patches Donald - did the same thing myself a couple of weeks ago...) G =-=-=-=-=-= Newsgroups: sci.crypt,alt.security,alt.security.pgp From: alexb@minerva1.bull.it (Alessandro Bottonelli) Subject: Questions about US/Canadian Laws about public encryption Date: Sat, 5 Dec 1992 15:39:54 GMT I have been following the security related groups for a while trying to understand all the discussion going on about the Legality of Crypto Tecniques, and I haven't been able to understand the following: (1) Is feeding public data or telephone networks with crypted data illegal or those who posted articles on the subject were just wishing it were made illegal ??? (2) Is it illegal to crypt any form of communication (like regular mail) or, as above, people are just wishing it were ? (3) Are there any signs that legislators are going or will regulate the subject in the near or mid-term future. All the above questions are for the USA and Canada. On my part I did read carefully my contract with the Italian Phone COmpany and I haven't been able to find any clause specifying I cannot crypt my voice or data ... Post or e-mail your replies ... -- == Alex Bottonelli / Bull Italia BSP | FAX : +39-(0)2-6779/8463 == == I.S./W.S./Network Security Officer | PHONE: +39-(0)2-6779/8324 == == E-MAIL: A.Bottonelli@it12.bull.it | (BullCom users dial 260+extension) == == BULLTX: /BULLX/IT12X/BOTTONELLI A. | == =-=-=-=-=-= Newsgroups: sci.crypt,alt.security,alt.security.pgp From: David Banisar Subject: Re: Questions about US/Canadian Laws about public encryption Date: Sat, 5 Dec 1992 18:41:08 GMT In article Alessandro Bottonelli, alexb@minerva1.bull.it writes: >I have been following the security related groups for a while trying >to understand all the discussion going on about the Legality of >Crypto Tecniques, and I haven't been able to understand the following: > > (1) Is feeding public data or telephone networks with crypted data > illegal or those who posted articles on the subject were just > wishing it were made illegal ??? > > (2) Is it illegal to crypt any form of communication (like regular > mail) or, as above, people are just wishing it were ? > > (3) Are there any signs that legislators are going or will regulate > the subject in the near or mid-term future. > >All the above questions are for the USA and Canada. On my part I did read >carefully my contract with the Italian Phone COmpany and I haven't >been able to find any clause specifying I cannot crypt my voice or data ... > >Post or e-mail your replies ... In a nutshell, it is not illegal to write, use or distribute encryption software or hardware in the US and Canada subject to copyright and patent law or if the info is classified (ie a NSA encryption program). It is illegal, by regulations (which have the force of law) to export encryption software without prior permission from the Dept. of State (which defers to the National Security Agency on crypto matters). Those regulations are available in the Federeal Register. The law enforcement and intelligence communities have been attempting for years to prevent encryption from becoming widely available. The NSA has threated several inventors over the past 15 years with the patent secrecy act, classifying inventions that use crypto. They have backed off a few times due to bad publicity but may have succeeded many more times that we dont know about. The FBI (or other LE) asked Senator Biden in 1991 to insert a resolution in the Omnibus Crime bill that asked phone companies to prove message traffic to LE in "plaintext" (ie unencrypted) when required by law. The fear was that this provision could have been easily and innocously changed to become enforceable. This provision was removed after many, many people publicly opposed it. The FBI has said numerous times in the last few months that are are working on ways of dealing with encryption and will introduce something in the future about it. They have also publicly stated (Asst. Director Al Bayse in Fed. Computer Week, Nov. 1992) that they will reintroduce the Digital Telephony program in 1993. Dave Banisar CPSR Washington Office =-=-=-=-=-= Newsgroups: sci.crypt,alt.security,alt.security.pgp From: rcain@netcom.com (Robert Cain) Subject: Re: Questions about US/Canadian Laws about public encryption Date: Sat, 5 Dec 1992 22:09:04 GMT alexb@minerva1.bull.it (Alessandro Bottonelli) writes: : I have been following the security related groups for a while trying : to understand all the discussion going on about the Legality of : Crypto Tecniques, and I haven't been able to understand the following: : : (1) Is feeding public data or telephone networks with crypted data : illegal or those who posted articles on the subject were just : wishing it were made illegal ??? Not yet according to specific statute. : : (2) Is it illegal to crypt any form of communication (like regular : mail) or, as above, people are just wishing it were ? Not yet according to specific statute. : : (3) Are there any signs that legislators are going or will regulate : the subject in the near or mid-term future. There was a defeated attempt at a legislative rider that would force communictions carriers that provided encryption services to provide the clear text to LE under court order. Nothing has been introduced, although there has been much speculation, to prevent the marketing of a crypto device for attachment to a phone line. (That would be sorta hard by now if one considers PC's and modems to intrinsically be such devices.) There may be U.S. national security laws broad enough to stop a potential seller of such a device and I have been told that under such laws (of which I know little by definition) a stop order can be issued by a court which you must obey but can't even open because it carries a top secret seal and furthermore you cannot even discuss it without looking at Leavenworth. So it is entirely possible that hidden laws exist to prevent sale of such devices, have been used and we would not know it under the umbrella of U.S. national security. If anyone knows this to be false I would love to be wrong. Conversely if anyone can verify it I would appreciate that. Bob -- Bob Cain rcain@netcom.com 408-358-2007 "There are some strings. They're just not attached." Victoria Roberts PGP 1.0 or 2.0 public key available on request. =-=-=-=-=-= Newsgroups: sci.crypt,alt.security,alt.security.pgp From: karn@servo.qualcomm.com (Phil Karn) Subject: Re: Questions about US/Canadian Laws about public encryption Date: Sun, 6 Dec 1992 08:26:00 GMT In article <1992Dec5.220904.24510@netcom.com> rcain@netcom.com (Robert Cain) writes: >: (3) Are there any signs that legislators are going or will regulate >: the subject in the near or mid-term future. I am unaware of any official proposals to regulate the private use of cryptography within the US. However, several private individuals, notably Dr. Dorothy Denning of Georgetown University, have proposed regulations such as key registration. Given the outcry against both the original S.266 and the FBI Digital Telephony Initiative, these proposals have little realistic chance of becoming law soon. But this is a politically charged topic and substantial vigilance is appropriate. Anyone concerned with protecting their right to privacy through encryption would be well advised to rebut such misguided and dangerous proposals wherever they appear. >There may be U.S. national security >laws broad enough to stop a potential seller of such a device and I >have been told that under such laws (of which I know little by definition) >a stop order can be issued by a court which you must obey but can't even >open because it carries a top secret seal and furthermore you cannot even >discuss it without looking at Leavenworth. So it is entirely possible that >hidden laws exist to prevent sale of such devices, have been used and we >would not know it under the umbrella of U.S. national security. The only US law of which I am aware that could fall into this category is the Invention Secrecy Act of 1951. If you file a patent application on a topic that the government considers to relate to national security, the government has the option of issuing you an "invention secrecy order" that prohibits you from disclosing your invention to anyone who doesn't already know about it. This happened several times in the late 1970s with various communication privacy inventions (Prof. George I Davida of the University of Wisconsin was one such victim). Apparently the law specifies that secrecy orders expire within 1 year unless a "state of national emergency" exists, in which case the secrecy orders continue as long as the emergency. And it wasn't until Sept 1978 that President Carter bothered to end the technical state of emergency invoked by President Truman during the Korean War. (Reference: "The Puzzle Palace" by James Bamford, pp. 445-449.) Yes, this really happened in the United States of America. And you probably thought that only third world military dictatorships used contrived states of emergency to suppress individual civil rights. There is a theory that RSA was deliberately published before patent applications were filed in order to avoid a possible secrecy order. Considering the contemporary secrecy orders and the threats issued at the time by a supposedly "unauthorized" NSA employee against RSA's inventors when they presented their first papers, this was probably a very real concern. So it's possible that they deliberately chose to forego foreign patent protection (since publication immediately waives patent filing rights in all countries but the US) as preferable to having a secrecy order clamped on all uses of RSA. So non-US users enjoy license-free use of RSA thanks to this particular set of quirks in the American legal system. Phil =-=-=-=-=-= From: "Andrew A. Chernov, Black Mage" Newsgroups: comp.unix.bsd,alt.security.pgp Subject: [386bsd] right patch for pgp port Date: Mon, 07 Dec 92 00:44:55 +0300 Hi. Recently I see in news some patch for pgp port to 386bsd. I check it and shure that it is only partial and non-elegant solution. Main problem are that 386bsd's ctype.h incorrect define tolower and toupper. This is not for pgp only but for other programs too, so we need to correct ctype.h instead of pgp in this case. This patch touch: /usr/include/ctype.h (386bsd bug fix) fileio.c makefile.unx Last two file fixes also different with previously posted patch. *** /usr/include/ctype.h.was Sat Feb 29 03:13:14 1992 --- /usr/include/ctype.h Sun Dec 6 23:49:03 1992 *************** *** 59,66 **** #define isgraph(c) ((_ctype_ + 1)[c] & (_P|_U|_L|_N)) #define iscntrl(c) ((_ctype_ + 1)[c] & _C) #define isascii(c) ((unsigned)(c) <= 0177) ! #define toupper(c) ((c) - 'a' + 'A') ! #define tolower(c) ((c) - 'A' + 'a') #define toascii(c) ((c) & 0177) #endif /* !_CTYPE_H_ */ --- 59,68 ---- #define isgraph(c) ((_ctype_ + 1)[c] & (_P|_U|_L|_N)) #define iscntrl(c) ((_ctype_ + 1)[c] & _C) #define isascii(c) ((unsigned)(c) <= 0177) ! #define _toupper(c) ((c) - 'a' + 'A') ! #define _tolower(c) ((c) - 'A' + 'a') ! #define toupper(c) (islower(c) ? _toupper(c) : (c)) ! #define tolower(c) (isupper(c) ? _tolower(c) : (c)) #define toascii(c) ((c) & 0177) #endif /* !_CTYPE_H_ */ *** fileio.c.was Mon Aug 31 05:02:46 1992 --- fileio.c Sun Dec 6 23:59:49 1992 *************** *** 250,257 **** --- 250,261 ---- #ifndef MAX_NAMELEN #if defined(AMIGA) || defined(NeXT) #define MAX_NAMELEN 255 + #else + #ifdef FILENAME_MAX + #define MAX_NAMELEN FILENAME_MAX #endif #endif + #endif void truncate_name(char *path, int ext_len) { /* truncate the filename so that an extension can be tacked on. */ *************** *** 260,266 **** int namemax; #ifdef MAX_NAMELEN /* overrides the use of pathconf() */ ! namemax = MAX_NAMELEN #else #ifdef _PC_NAME_MAX strcpy(dir, path); --- 264,270 ---- int namemax; #ifdef MAX_NAMELEN /* overrides the use of pathconf() */ ! namemax = MAX_NAMELEN; #else #ifdef _PC_NAME_MAX strcpy(dir, path); *** makefile.unx.was Thu Sep 3 00:27:00 1992 --- makefile.unx Mon Dec 7 00:01:52 1992 *************** *** 60,65 **** --- 60,66 ---- @echo " \"make sysv_386\" for SVR4 386 with asm primitives" @echo " \"make x286\" for XENIX/286 with asm primitives and unproto" @echo " \"make ultrix\" for DEC 4.2BSD Ultrix" + @echo " \"make 386bsd\" for Public Domain 386bsd" @echo " \"make rs6000\" for RS6000 AIX" *************** *** 93,98 **** --- 94,103 ---- linux: $(MAKE) all CC=gcc LD=gcc OBJS_EXT=80386.o \ CFLAGS="-O -DUNIX -DUNIT32" + + 386bsd: + $(MAKE) all LDFLAGS=-s OBJS_EXT=80386.o \ + CFLAGS="-pipe -fstrength-reduce -O -DUNIX -DUSE_SELECT -DUNIT32" sunspc: $(MAKE) all CC="ccspc -B/1.8.6/sun4 -ansi -w -I/usr/include" \ -- In-This-Life: Andrew A. Chernov | "Hay mas dicha, mas contento Internet: ache@astral.msk.su | "Que adorar una hermosura Organization: The RELCOM Corp., | "Brujuleada entre los lejos Moscow, Russia | "De lo imposible?!" (Calderon) =-=-=-=-=-= Newsgroups: comp.unix.bsd,alt.security.pgp From: karn@servo.qualcomm.com (Phil Karn) Subject: Re: [386bsd] right patch for pgp port Date: Mon, 7 Dec 1992 06:06:52 GMT PGP also triggers a bug in the fseek() library function that 386BSD inherits from NET-2. Here's the diff to /usr/src/lib/libc/stdio/fseek.c, courtesy of Branko Lankester: *** fseek.c.orig Tue May 7 13:43:56 1991 --- fseek.c Mon Nov 23 23:44:37 1992 *************** *** 215,220 **** --- 215,221 ---- if ((*seekfn)(fp->_cookie, curoff, SEEK_SET) == POS_ERR) goto dumb; fp->_r = 0; + fp->_p = fp->_bf._base; if (HASUB(fp)) FREEUB(fp); fp->_flags &= ~__SEOF; =-=-=-=-=-= From: davidsen@ariel.crd.GE.COM (william E Davidsen) Newsgroups: comp.unix.bsd,alt.security.pgp Subject: Re: [386bsd] right patch for pgp port Date: 7 Dec 92 15:44:59 GMT In article , ache@astral.msk.su (Andrew A. Chernov, Black Mage) writes: | Hi. | Recently I see in news some patch for pgp port to 386bsd. | I check it and shure that it is only partial and non-elegant solution. | Main problem are that 386bsd's ctype.h incorrect define tolower | and toupper. This is not for pgp only but for other programs too, | so we need to correct ctype.h instead of pgp in this case. | ! #define _toupper(c) ((c) - 'a' + 'A') | ! #define _tolower(c) ((c) - 'A' + 'a') | ! #define toupper(c) (islower(c) ? _toupper(c) : (c)) | ! #define tolower(c) (isupper(c) ? _tolower(c) : (c)) The only problem with this code is that existing working code will break, because you evaluate the argument twice. Example: char str[] = "Any string", *sptr = str; int m; for (m=0; m < 4; ++m) myproc(toupper(*(sptr++)); This not only breaks the logic by stepping the pointer twice per character but also returns the wrong values. I would suggest that the only really correct way to do this is by table lookup (don't forget the AND, either). #define toupper(c) _ALLupper[(c) & 0xff] -- bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345 Keyboard controller has been disabled, press F1 to continue. =-=-=-=-=-= Newsgroups: alt.security.pgp Subject: PGP-compatible archiver released From: pgut1@cs.aukuni.ac.nz (Peter Gutmann) Date: Mon, 7 Dec 1992 10:02:43 GMT I just thought I'd mentioned that a PGP-compatible archiver is now available. This uses the same keyrings as PGP, but is an archiver rather than an encryption program. As such it doesn't offer most of the special features of PGP, but does have the following: - Better compression than Arj, Zip, Zoo, etc (based on the Calgary compression corpus, a standard benchmark for compression programs) - PGP-compatible public-key and conventional encryption of archives - *Real* data authentication using digital signatures. - Multi-disk archives (your mileage may vary depending on the OS) - Internationalization support (currently available in four languages, built-in support for multiple character sets). - Quality Postscript documentation (600K worth) - Easy portability to virtually any OS (currently exists for Amiga, Archimedes, Atari ST, Macintosh, MSDOS, OS/2 (16 and 32-bit), and Unix). - Availability of the source code to anyone who wants it. The following versions are available from garbo.uwasa.fi (128.214.87.1): 114243 Nov 20 07:08 garbo.uwasa.fi:/pc/arcers/hpack78.zip 146470 Dec 3 01:01 garbo.uwasa.fi:/pc/doc-soft/hpack78d.zip 511827 Dec 3 14:46 garbo.uwasa.fi:/pc/source/hpack78s.zip 667464 Dec 5 16:43 garbo.uwasa.fi:/unix/arcers/hpack78src.tar.Z where hpack78.zip is the MSDOS executable, hpack78d.zip is the Postscript documentation, hpack78s.zip is the source code, and hpack78src.tar.Z is the source code again but in tar.Z format (note that the latter is a tiny bit more recent that hpack78s.zip and contains changes for the NeXT). There is a (rather primitive) Macintosh executable somewhere on garbo as well, possibly /mac/arcers/hpack78mac.cpt. In order to keep the size of the distribution down, no executables have been provided for the Amiga, Atari ST, and Archimedes versions, but these can be easily created from the source code. There are OS/2 16 and 32-bit executables as well but an archive site for them is still under negotiation (there are obvious problems with placing them on the standard US OS/2 sites :-). Before using HPACK, you should at least read the section of the readme file pertaining to your OS - I could only do so much in terms of testing and cleaning up the different versions, since I often didn't have access to the hardware to try it out on. In particular multidisk archives don't work properly on most systems yet, and won't work until I can get to a machine, or someone else gives me a hand with it (hint hint). There should also be a VMS port, but again I don't have access to the hardware (sigh). Peter. -- pgut1@cs.aukuni.ac.nz||p_gutmann@cs.aukuni.ac.nz||gutmann_p@kosmos.wcc.govt.nz peterg@kcbbs.gen.nz||peter@nacjack.gen.nz||peter@phlarnschlorpht.nacjack.gen.nz (In order of preference - one of 'ems bound to work) =-=-=-=-=-= Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc From: hmiller@lucpul.it.luc.edu (Hugh Miller) Subject: PGP v. 2.1 Released Date: Mon, 7 Dec 1992 20:49:36 GMT -----BEGIN PGP SIGNED MESSAGE----- PGP 2.1 Available - ----------------- Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. This new version of the world's most popular and politically controversial public key encryption program has numerous bug fixes over version 2.0, and several new features. For example, you can now display the MD5 hash of a public key, to facilitate verifying it over the telephone with the owner of that public key. Also, it is now possible to send via email an unencrypted signed message without putting the whole message in Radix-64 format, to make it possible to read without PGP. This is analogous to the PEM MIC-CLEAR signed message functionality. PGP 2.1 incorporates many patches from the user community to port it to more platforms. And it runs faster. Also, a lot of annoying bugs and ergonomic oversights have been fixed. PGP 2.0 fans will find many rough edges have been smoothed out. The filenames are pgp21.zip for the MSDOS executable release, and pgp21src.zip for the source code release. You must have PKUNZIP version 1.1 or later to unzip them, or they won't unzip. The primary initial FTP sites that have it are: Finland: nic.funet.fi (128.214.6.100) Directory: /pub/unix/security/crypt/ Italy: ghost.dsi.unimi.it (149.132.2.1) Directory: /pub/security/ As previously, this prohibited and politically popular program will probably propagate through the same channels as PGP 2.0. Of course, if you live in the USA, you really shouldn't be using it. If you have any questions about where else to get it, contact Hugh Miller, at hmiller@lucpul.it.luc.edu. Hugh can send you the latest evolving list of FTP sites, BBS phone numbers, and other sources. Philip Zimmermann Phil's Pretty Good Software -----BEGIN PGP SIGNATURE----- Version: 2.1 iQCVAgUBKyLbAuJ13g7/Z/cLAQFxoAP+OqIqZu2zfA7LycuBJmaF0cms6xyYYok+ ifFW5hIKYUDqvVwLQg5kSXRIUY9fbSXaox6bnww+2YCoEacbzMAAVgTiw8TU7QG0 JryTOHsUIihq9JNBOQ5ONfmHzH0w2gaQ5SGEcJK93typoyvNQMtdtVSeIfkl6ImJ vs/OHzY5LiU= =nV70 -----END PGP SIGNATURE----- -- Hugh Miller | Dept. of Philosophy | Loyola University of Chicago Voice: 312-508-2727 | FAX: 312-508-2292 | hmiller@lucpul.it.luc.edu =-=-=-=-=-= From: ujacampbe@memstvx1.memst.edu (James Campbell) Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc Subject: Re: PGP v. 2.1 Released Date: 8 Dec 92 09:58:51 -0600 >From a cleartext news release signed by Phil Zimmermann (I LOVE the sound of that!): >Pretty Good Privacy (PGP) Version 2.1 is now available, from Europe. >This new version of the world's most popular and politically >controversial public key encryption program has numerous bug fixes >over version 2.0, and several new features. Thanks, Mr. Z. This is an _outstanding_ update to an already great piece of software. I've been playing with it since I got it yesterday, and I absolutely _love_ the enhancements. > ...it is now possible to send via email an >unencrypted signed message without putting the whole message in >Radix-64 format, to make it possible to read without PGP. This is >analogous to the PEM MIC-CLEAR signed message functionality. My _favorite_ enhancement! This is something we've all wanted, and its implementation is superb. Just set up a 4DOS alias (or, if you're still using COMMAND.COM, an analgous batch file) that reads pgpc = `pgp -sta +clearsig=on` and 'pgpc filename' will generate a signed cleartext message! This is the PGP we've all been waiting for! > ...PGP 2.0 fans will find many rough edges have been smoothed out. That's the truth! Alas, though, they've even smoothed out the one rough edge with which I scratched my itch for even _better_ security. PGP 2.0 had allowed me to generate public/private key pair with up to 1136 bits; the 2.1 incarnation _draws_the_line_ at 1024 bits ("military grade"). Thankfully, it still accepts my 1136-bit key with grace. So, if you're using a >1024-bit key, or plan to change to one, be sure you keep a copy of your PGP 2.0 executable, to use for generating 1025- to 1136-bit keys after you upgrade to 2.1. >As previously, this prohibited and politically popular program will >probably propagate through the same channels as PGP 2.0. Of course, >if you live in the USA, you really shouldn't be using it. OOPS! Forget everything I said! I was never here! ;-) =========================================================================== James Campbell, Math Sciences Department, MSU; ujacampbe@memstvx1.memst.edu --------------------------------------------------------------------------- =-=-=-=-=-= Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc Subject: Re: PGP v. 2.1 Released From: jsteiner@anwsun.phya.utoledo.edu (jason 'Think!' steiner) Date: 8 Dec 92 15:51:34 EST great program! especially the clearsig and pipe options. one question: how do i set up a vi key to do a cleartext sign? i tried assigning a key to 'pgp -fast +clearsig=on'. this works as a file pipe, but when i try to use it in vi it hangs on asking for my password. i know how to set my password as an environment var, but i'd rather it prompted me each time. jason =-=-=-=-=-= Newsgroups: alt.security.pgp,alt.security,sci.crypt,talk.politics.misc From: strnlght@netcom.com (David Sternlight) Subject: Re: PGP v. 2.1 Released Date: Tue, 8 Dec 1992 17:29:44 GMT I don't understand the comment that "if you're living in the U.S.A. you probably shouldn't be using it" (pgp2.1). I thought it was o.k. for personal, educational, or research use, and only an infringement if used commercially without permission of PKP. Can anyone clear this up once and for all? Thanks; =-=-=-=-=-= From: hmiller (Hugh Miller) Subject: PGP 2.1 Site List To: info-pgp Date: Wed, 9 Dec 92 2:50:32 CST (Last modified: 0820 UTC, 9 Dec 92) PGP v. 2.1 is gradually making its way out into the electronic world. It has been posted to the FidoNet Software Distribution Network and should soon be up on most if not all Canadian and U.S. nodes carrying SDN software. On the Internet, there are many sites to try for anonymous ftp: nic.funet.fi (128.214.6.100) /pub/unix/security/crypt/pgp21.zip (MSDOS binaries + docs) /pub/unix/security/crypt/pgp21src.zip (Source code + docs) /pub/unix/security/crypt/pgp21.tar.Z (Source code in compressed tar format) van-bc.wimsey.bc.ca (192.48.234.1) /pub/crypto/PGP-2.1/pgp21.zip /pub/crypto/PGP-2.1/pgp21src.zip /pub/crypto/PGP-2.1/pgp21.tar.Z ghost.dsi.unimi.it (149.132.2.1) /pub/crypt/pgp21.zip /pub/crypt/pgp21src.zip /pub/crypt/pgp21.tar.Z pencil.cs.missouri.edu (128.206.100.207) /pub/crypt/pgp21.zip /pub/crypt/pgp21src.zip /pub/crypt/pgp21.tar.Z soda.berkeley.edu (128.32.149.19) /pub/cypherpunks/pgp/pgp21.zip /pub/cypherpunks/pgp/pgp21src.zip /pub/cypherpunks/pgp/pgp21.tar.Z eugene.utmb.edu (129.109.9.21) pub/pgp/pgp21.zip pub/pgp/pgp21src.zip pub/pgp/pgp21.tar.Z For those lacking ftp connectivity to the net, nic.funet.fi also offers the files via mail. Send the following mail message to mailserv@nic.funet.fi: ENCODER uuencode SEND pub/unix/security/crypt/pgp21src.zip SEND pub/unix/security/crypt/pgp21.zip This will deposit the two zipfiles, as 15 batched messages, in your mailbox with about 24 hours. Save and uudecode. The Northern Lights BBS in Troy, NY, has both PGP21.ZIP and PGP21SRC.ZIP for free download. Call (518) 237-2163 at 300-2400 bps 8N1 24 hours a day. Then login directly to the pgp account as follows: tnllogin: pgp Password: key and help yourselves. Thanks to Daniel Ray of tnl for this fine service. Another private BBS from which you can obtain PGP for the simple price of the long-distance call time is the Grapevine BBS, the largest BBS in Arkansas. It's run by Jim Wenzel in Little Rock. John Eichler, a PGP user at Grapevine, sent me the following information for your edification and enlightenment: > The GRAPEVINE BBS in Little Rock is the largest BBS in Arkansas. To > help people obtain a copy of PGP21, the GRAPEVINE has set up a special > account for this purpose. The following phone numbers are applicable > and should be dialed in the order presented (i.e., the top one first > since it is the highest speed line). > > (501) 753-6859 > (501) 753-8121 > (501) 791-0124 > (501) 753-4428 > (501) 791-0125 > > When asked to login use the following information. > > name: PGP USER ('PGP' is 1st name, 'USER' is 2nd name) > password: PGP > > There is a special menu which one gets which shows the following > programs to be available. > > PGP21.ZIP = Dos Version of "Pretty Good Privacy" > PGP21SRC.ZIP = Source Code to PGP v2.0 > PGP20OS2.ZIP = OS/2 version of PGP v2.0 > PKZ110.EXE = Current version of DOS based PKzip > > Should you have any questions e-mail either me > (john.eichler@grapevine.lrk.ar.us) or the Sysop of the BBS whose address > is jim.wenzel@grapevine.lrk.ar.us. -- Thanks, John! If none of these sites do it for you, let me know. Film at 11. Best regards! -=- Hugh P.S.: If you come across sites where it's posted -- especially FREE ACCESS sites -- please drop me a line (info-pgp-request@lucpul.it.luc.edu). I'd like to maintain a current list as part of a PGP FAQ list. Thanks to the many correspondents who have helped to contribute to this list on an almost daily basis! Hugh Miller Info-PGP info-pgp-request@lucpul.it.luc.edu ***** End Info-PGP Digest ***** From clancy@first.org Wed Dec 9 17:36:00 1992 Return-Path: Received: from nkosi.well.sf.ca.us by well.sf.ca.us with SMTP (5.65c/SMI-4.1/well-921206-1) id AA21958; Wed, 9 Dec 1992 17:35:47 -0800 Received: from first.org (CSRC.NCSL.NIST.GOV) by nkosi.well.sf.ca.us (5.65c/SMI-4.1/nkosi-921112-1) id AA04468; Wed, 9 Dec 1992 17:35:34 -0800 Received: by first.org (4.1/NIST) id AA15683; Wed, 9 Dec 92 20:36:01 EST Date: Wed, 9 Dec 92 20:36:01 EST From: Kim Clancy Organization: FIRST, The Forum of Incident Response & Security Teams Posted-Date: Wed, 9 Dec 92 20:36:01 EST Message-Id: <9212100136.AA15683@first.org> To: aissecur@well.sf.ca.us Subject: virusl5.199 : >From virus-l@lehigh.edu Wed Dec 9 16:08:04 1992 Return-Path: Received: from csmes.ncsl.nist.gov by first.org (4.1/NIST) id AA15498; Wed, 9 Dec 92 16:06:57 EST Posted-Date: Wed, 9 Dec 1992 15:54:47 -0500 Received-Date: Wed, 9 Dec 92 16:06:57 EST Errors-To: krvw@cert.org Received: from Fidoii.CC.Lehigh.EDU by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA06768; Wed, 9 Dec 92 16:01:30 EST Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA29976 (5.65c/IDA-1.4.4); Wed, 9 Dec 1992 15:54:47 -0500 Date: Wed, 9 Dec 1992 15:54:47 -0500 Message-Id: <9212091957.AA00590@barnabas.cert.org> Comment: Virus Discussion List Originator: virus-l@lehigh.edu Errors-To: krvw@cert.org Reply-To: Sender: virus-l@lehigh.edu Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas >From: "Kenneth R. van Wyk" To: Multiple recipients of list Subject: VIRUS-L Digest V5 #199 Status: R VIRUS-L Digest Wednesday, 9 Dec 1992 Volume 5 : Issue 199 Today's Topics: Administrivia: Duplicates and missing digests (sigh) virus signatures (PC) Re: SCAN 95b doesn't find MtE in EXE files (PC) Fake Dir-II (PC) Re: Untouchable (PC) Re: Trojan detection/protection (PC) Re: AntiViral SW Leftovers (PC) VSHIELD, VIRSTOP, ... comparison ? (PC) RE: Dangerous bug in CHKDSK that comes with MS-DOS 5.0 (PC) (fwd) Integrity Management (PC) Re: Filler virus (PC) Odd Virus? HELP (PC) Not a stupid OS/2 Question (OS/2) Re: ViruScan v99 and OS/2 (OS/2) Re: Potentially stupid question (OS/2) (PC) FC on virus creation Re: Integrity Management Re: Second generation problems (Philosophy) A user's view of IBM's antivirus/2 (OS/2) Survey CLEAN-UP, VSHIELD, & WSCAN 99 uploaded to Simtel20 (PC) VIRUS-L is a moderated, digested mail forum for discussing computer virus issues; comp.virus is a non-digested Usenet counterpart. Discussions are not limited to any one hardware/software platform - diversity is welcomed. Contributions should be relevant, concise, polite, etc. (The complete set of posting guidelines is available by FTP on cert.sei.cmu.edu or upon request.) Please sign submissions with your real name. Send contributions to VIRUS-L@LEHIGH.EDU. Information on accessing anti-virus, documentation, and back-issue archives is distributed periodically on the list. A FAQ (Frequently Asked Questions) document and all of the back-issues are available by anonymous FTP on cert.org (192.88.209.5). Administrative mail (comments, suggestions, and so forth) should be sent to me at: . Ken van Wyk ---------------------------------------------------------------------- Date: Wed, 09 Dec 92 14:55:02 -0500 >From: Kenneth R. van Wyk Subject: Administrivia: Duplicates and missing digests (sigh) In the last VIRUS-L digest, there were a couple of messages that were inadvertantly duplicated from a previous digest. Due (I believe) to a mailer glitch, these entries had been sent to me multiple times. Sorry for any inconvenience. While on the subject of mailer glitches, some of you have been noticing duplicate or missing digests. Taking a SWAG, I'd say that these are due to the same mailer glitch. The problem(s) is being looked into. Again, sorry for any inconvenience. I'll be updating the archives on cert.org as soon as Issue 199 goes out, so feel free to look there for any missing digests. These things would, of course, explain why my incoming VIRUS-L queue is so long. I keep doing the same work over and over. :-) Now, let's see if _this_ one comes back to me... Cheers, Ken Kenneth R. van Wyk Moderator VIRUS-L/comp.virus Technical Coordinator, Computer Emergency Response Team Software Engineering Institute Carnegie Mellon University krvw@CERT.ORG (work) ken@THANG.PGH.PA.US (home) (412) 268-7090 (CERT 24 hour hotline) ------------------------------ Date: Sun, 06 Dec 92 18:57:02 -0500 >From: Kayvon Z. Sadeghi Subject: virus signatures (PC) Does anybody know where I can find a file that contains the signatures of different viruses? I found a zip file somewhere in the net, but apparently there is something wrong with the file and I can't unzip it. thanks in advance k1 - --- - ------------------------------------------------------------------------ PUSH, if that doesn't work PULL, if that doesn't work we're probably CLOSED - ------------------------------------------------------------------------ Kayvon Sadeghi k.sadeghi@ieee.org Voice:202/244-0789 ------------------------------ Date: Fri, 04 Dec 92 09:03:00 +0000 >From: Stefano_Turci@f108.n391.z9.virnet.bad.se (Stefano Turci) Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC) Hello Fridrik, in your message dated 25-11-92 you wrote: FS> However, one very strange thing....according to your information, my FS> scanner reports the files it finds to be infected with "MtE (?)", but not FS> "MtE" - now...this usually means that it finds a MtE signature string - FS> taken from the decrypted virus engine, instead of using an algorithmic FS> approach. That implies that the converted files contain a non-encrypted FS> MtE engine. You are right, in fact the converted files contained a non-encrypted copy of Mte. _ Ciao. /\\ _\\ \/teve. - --- Mercurio 1.10 * Origin: Move fast in the tunnels of the underground. (9:391/108) ------------------------------ Date: Fri, 04 Dec 92 09:36:00 +0000 >From: Stefano_Turci@f108.n391.z9.virnet.bad.se (Stefano Turci) Subject: Fake Dir-II (PC) Hi Fridrik, I have discovered a strange behaviour when I scan a little file using F-prot 2. 06a. This is what appears on the screen: - ----------------------------------------------------------------- F-PROT anti-virus program - Version 2.06a - November 1992 Copyright (c) 1990-1992, Frisk Software International Loading virus information. C:\0\GM4.COM Possibly a new variant of DIR-II - ----------------------------------------------------------------- F-prot says that it is possibly a new variant of Dir-II, and it doesn't say that the file is infected by Dir-II, however I am a little worry about it because.....I am the author of that program. :-) I wrote that program using assembler, and I found the piece of source code that produces the above warning: - ------------------------------------------------ mov bx,offset message mov cx,46d decrypt: xor byte ptr [bx],0ffh inc bx loop decrypt - ------------------------------------------------ This is a simple routine that decrypts a string. Once compiled the bytes inside the exec are: - ----------------------------------- BB 03 01 B9 2E 00 80 37 FF 43 E2 FA - ----------------------------------- The program is 487 bytes long. I can only suppose that the virus uses a very similar decrypting routine, however I think there is something wrong in the way used by F-prot to search for new variants of Dir-II. In fact F-prot still announces a possibly new version of Dir-II even if I create a only-12 bytes long file and fill it with those bytes above mentioned. Of course a fake alarm is better than a true infection, but if my clients will use F-prot to scan their own hard disks I'll be ruined ! :-) _ Ciao. /\\ _\\ \/teve. - --- Mercurio 1.10 * Origin: Move fast in the tunnels of the underground. (9:391/108) ------------------------------ Date: Mon, 07 Dec 92 10:05:22 -0500 >From: Y. Radai Subject: Re: Untouchable (PC) I agree with almost everything in Vesselin Bontchev's reply to Rick Wirthlin on Untouchable. However, there was one passage which re- quires clarification: > There are about 17 ways a virus can infect a file, and the > generic disinfector can handle about one third of them. The authors > have promised to achieve about two thirds soon. The number of infection methods now recognized by UT is between 10 and 14, depending on how one counts them. (Like "number of known viruses", it's not a well-defined concept.) Regardless of the exact number, there's a strong possibility that Vesselin's first statement above will be misinterpreted by some readers, who might think that being able to handle only "one third of them" (i.e. of the *infection methods*) implies being able to disinfect only one-third of the *viruses*. In case anyone did get this impression, the percentage of viruses which can be disinfected by UT (as estimated by the authors, not according to the marketing hype) is about 99% on the common viruses, and greater than 90% on other viruses. Y. Radai Hebrew Univ. of Jerusalem, Israel RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: 07 Dec 92 18:24:50 +0000 >From: tck@fold.ucsd.edu (Kevin Marcus) Subject: Re: Trojan detection/protection (PC) YUNSANJ@YaleVM.YCC.Yale.Edu (Lou) writes: >With my limited understanding of this subject, i assume that a trojan >is NOT technically a virus but a programming modification that alters >programs and causes them to run harmfully. I even saw a trojan batch >file in Digital Free Press (volume 1, issue 4) which would *gasp* do >an absolute write to the first 9 sectors of my Hard drive! How >malicious! I was wondering, how do i protect myself? is there a >version of McAfee's V-Shield for Trojans? and if i do get hit, how do >i go about recovering?! You don't recover, usually. McAfee's Scan identifies a few of the trojans that are ou there, including, for example, the Twelve Tricks trojan. F-Prot identifies FAR more trojans, but these are virus scanners, and not trojan scanners, so you shouldnt' be expecting them to. A Trojan is pretty mcuh a program that does some unwanted action while you think it's doing something good. For example, if you ran some word processor, and it started deleting your files, then you would be the victim of a trojan. Many trojans use absolute sector writes, like the trojan you mentioned because they're relatively easy to code, others make a mess of your hard drive by making directories, files, or changing other file related things. I have seen two programs designed to create trojans, the VCL, which generates some buggy code, and the trojan construction kit. The trojan kit is explicitly dangerous because you don't need a compiler for it, and it comes with a time bomb faciltity, to change real programs into time bombs. The first version of this program is very buggy, but the second seems to work well. None of the anti-virus programs that I have used detected anything from this program. A long time ago I wrote a generic trojan scanner, TSCAN, which will identify smoe trojans that use absolute sector writes. The problem with it is that a lot of programs do that, legitimately, like the Norton Utilities, FORMAT.COM, and hard drive optimizers.... I am working on another version which will provide far better results to be released after my MtE detector. - -- || Kevin Marcus, Computer Virologist. (619)/457-1836; RE-xxx, TSCAN || || INET: tck@bend.ucsd.edu []-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[] || tck@fold.ucsd.edu || All I wanted was a Pepsi... || || datadec@watserv.ucr.edu || And she wouldn't give it to me...|| ------------------------------ Date: 07 Dec 92 13:32:38 -0500 >From: 739chan1@gw.wmich.edu Subject: Re: AntiViral SW Leftovers (PC) padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes: > Luca Parisi asks about a leftover string "Carmel" plus other oddities > in files. > > It is my understanding that the Central Point Anti-Virus program was > originally obtained from a company called "Carmel" in Isreal with > an interesting background. I *suspect* this is the source. There was a product called Turbo Anti Virus (TNTVirus) produced by a Carmel company in Israel. It was VERY similar to CPAV. Now that you mentioned it, I must agree that CPAV was based on it. The original program offered on-the-fly checksums, which it had previously appended to the files to be checked. I would think they's include the company name, i.e. "Carmel". Lemming. ------------------------------ Date: Mon, 07 Dec 92 14:42:18 -0500 >From: Mike Ramey Subject: VSHIELD, VIRSTOP, ... comparison ? (PC) I have found Robert Slade's quick comparison (and his longer reviews) of several anti-viral programs very helpful; they prompted me to try F-PROT and VIRx, in addition to the McAfee suite of programs which I have been using for several years. Is it possible that the three of you (McAfee, Frisk, and Slade) could cooperate to produce a point-by-point comparison of VSHIELD and VIRSTOP? One of my questions is this: VSHIELD intercepts a keyboard reboot and checks for the presence of an infected diskette in the boot diskette drive; it does not allow booting from a (boot-sector?) infected diskette. Does VIRSTOP have this function? What other differences are there? - -Mike Ramey, 685-0940, 171 Wilcox, U W Civil Eng, FX-10, Seattle WA 98195. ------------------------------ Date: Mon, 07 Dec 92 16:27:37 -0500 >From: Mike Ramey Subject: RE: Dangerous bug in CHKDSK that comes with MS-DOS 5.0 (PC) (fwd) How can you tell if you have MS-DOS version 5.00a or not ? I called Microsoft and requested the updated version for my computer labs, even tho' we have not encountered the failure conditions yet. I was told that in MS-DOS version 5.0a, the date on COMMAND.COM is 11-11-91. I have not yet received the updated version, so I cannot confirm that. (My current DOS-5 COMMAND.COM date is 4-09-91.) If I learn anything different, I will post it. - -Mike Ramey, 685-0940, 171 Wilcox, U W Civil Eng, FX-10, Seattle WA 98195. >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) >Newsgroups: comp.virus >Subject: Dangerous bug in CHKDSK that comes with MS-DOS 5.0 (PC) >Date: 2 Nov 92 18:11:33 GMT > (This is NOT an official report from Microsoft or AT&T. It's just > my own friendly posting to try to help) > > Program: chkdsk > O/S : MS-DOS 5.0 > > Symptoms: Users running chkdsk with the /f option have 256 copies > of the FAT written onto their hard disk starting at the > first copy of the FAT. The result being that all directory > information and a significant amount of the data in the data > area are irrecoverably destroyed. > > Affected users: Any users using 256 sector FAT's. > > How to tell if you're at risk: > > Run chkdsk WITHOUT the '/f' option and check the > "Total allocation units on disk". If this number is > more than 65280, you're at risk. DO NOT USE CHKDSK TO > CORRECT ANY DISK PROBLEMS if this is the case. You'll > trash your disk. > > Solution: Call Microsoft and request the 5.00A upgrade. They know > about the problem and they've fixed it. They've also done > some diddling with the following programs: (though I don't > know what they did to them.) > > deloldos.exe diskcomp.com diskcopy.com > doshelp.exe dosshell.exe dosswap.exe > emm386.exe expand.exe format.com > himem.sys mirror.com qbasic.exe > recover.exe setver.exe undelete.exe > xcopy.exe > > Apparently, the only place that Microsoft posts information of > known bugs is on CompuServe in something they called the Microsoft > Knowledgebase. If there's anyone out there who regularly reads this > forum on CIS, maybe you'ld like to volunteer to cross-post to this > group? ------------------------------ Date: Mon, 07 Dec 92 16:27:49 -0500 >From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Integrity Management (PC) >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) >OK, but you still didn't answer my question. My question was aimed >towards those who think that they can live with imperfect detection. >Note, I didn't say imperfect MtE detection - after all, the current >MtE-based viruses are not spread at all. For one, I cannot live with imperfect detection. What I can live with is 100% detection but a lesser identification (not wrong identification but "this file has been changed"). An interesting case in point is Vern Buerg's "LIST" which carries all of its data internally. One test I use is to change a color or filter (going from wrap(W) to non-wrap (w) changes bytes at offset 2Ah & 2Bh in version 6.1a) & see if anybody notices - - some don't. Seems like we should be about due for some "next generation" products, products that can detect a one-byte change in any program but are smart emough to know that a one byte change is not likely to be a virus. Other expected "features" would be: 1) Multilevel validation - secondary programs that validate whether or not the protection program is working properly. 2) TSR awareness - what programs are expected to change memory allocations and which are not. 3) Interrupt path verification & recovery. 4) DOS locations, sizes, and expected values specific to the particular PC. 5) Ability to temporarily disengage certain functions for maintenance without having to remove the entire package. 6) Partitioning support. 7) Ability to detect an attempt to write to an executable 8) Novell/Pathworks/LAN Man/LAN Server/Vines support >As far as I know, Prof. Eugene Spafford and a few others from Purdue >University are working on a platform-independent user-programmable >scanner. It will be released in source, free of charge. Initially it >will have routines to access Unix file systems, but since it will be >written in C++, nothing will prevent other people from writing the >appropriate interface to DOS, MacOS, AmigaDOS, or whatever. As you see >- - no deep secrets. The problem is that a platform independant management program is going to have a hard time detecting platform-dependant low-level attacks. Consider for a moment malicious software that tries to go resident in the disk buffers. To work it must recognize the differences between buffers used by DOS 3.x and those of higher versions. So must an integrity management routine. Gene & Co. at Purdue are doing important work but it must be realized that you cannot get all of the way with a platform-independant solution. A long way certainly & would work on a PC with Jerusalem & Sunday, but how about a low-level infection such as MICHELANGELO or FORM ? These depend on the platform. Of course the real answer might be for a generic "kernel" with attachable platform-specific modules that are assembled on installation. Not difficult, just different. >> It occurs to me that a given integrity checker >> should not rely on secrecy of its own checksumming algorithm, for >> instance, for its "security" -- rather, algorithms should be freely >> distributable [because someone will soon figure it out anyway!] and I agree but take it one step further, again the algorithm should be tailored to the specific machine and use a different seed on each - this in no way weakens the algorithm but gives each PC a different signature for a particular file. Break one machine and "malware" must start all over again on the next. >In general, that's true, but there are still some "trade secrets"... >:-) Like fast file access, how to implement intelligent file checking >(i.e., only selected parts of the files), anti-stealth techniques, >etc. Most of these are just examples of "bypass DOS" since it is what is slow or "stealthed" and are evident to anyone who fanatically studies the architecture (admittedly not many do). Of course we all have our notebooks like mine on DOS boot record requirements but I do not consider it secret, just incomplete and not fully verified. IMHO the real problem is that there are no standrds. What we are dealing with is a multi-billion dollar garage industry that "just growed". Just as a trivial example, no-one would buy a PC that isn't "100% compatable" yet how many in the audience know *exactly* what that means ? (no peeking). Is a PS/2 "100% Compatable" ? A Zenith 248 ? Careful now. I postulate that every manufacturer has a different idea of just what "100% compatable" is and that no-one really is (nor would they want to be), yet how many Anti-Virals are sold as "one size fits all" ? At least some are starting to say DOS 3.x & higher and not 2.0 any more. Of course open standards will require the giving up of some secrets by the manufacturers, mostly those involving undocumented "back doors", but these are not really secret any more and the manufacturers claims (mostlt Microsoft's) of "if we document them, we'll have to support them". Just do not ring true. All the documentation needs is a note that "this function may be superceeded". But like an MtE detector, incomplete documentation is worse than none at all. Enough, Padgett ps obscure Bug report: SCAN v99 occasionally hangs with a "data read error" when scanning a large number of files with the /A switch on a SuperStor Pro compressed disk in a Zenith 386/sx desktop. This happens only occasionally and was only on certain Harvard Graphics data files but always on the same ones (HG can read them just fine though & v95 had no problem). Aryeh has been notified. ------------------------------ Date: 07 Dec 92 23:50:57 +0000 >From: tck@fold.ucsd.edu (Kevin Marcus) Subject: Re: Filler virus (PC) >> Scan 99 detected "Filler" active in the memory of my computer. >>When I booted from a write-protected floppy the nasty virus was not >>found, no matter how many times I tried. By the way, I have CPAV >>constantly running and it did not detect anything wrong. > >I've been reading in lots of places lately about Filler being detected >in memory and not being able to find it anywhere on disk. Always, it >turns out that the user is running CPAV. Seems a version of CPAV must >be leaving a signature of Filler in memory for everyone else to ID. > >BTW, you will not (or should not :-) ) see this conflict with NAV. >NAV does a more sophisticated search through memory with knowledge of >where viruses store themselves. > Hmm. That doesn't sound like the most brilliant thing. It doesn't take too long to search through memory, and it's easy for a varient to move to a different place in memory. Or pick a random spot. And, yes, the problem is that CPAV does leave signatures in memory. And, it explicitly says NOT to use it with any other AV software. - -- || Kevin Marcus, Computer Virologist. (619)/457-1836; RE-xxx, TSCAN || || INET: tck@bend.ucsd.edu []-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[]-[] || tck@fold.ucsd.edu || All I wanted was a Pepsi... || || datadec@watserv.ucr.edu || And she wouldn't give it to me...|| ------------------------------ Date: Tue, 08 Dec 92 00:45:11 +0000 >From: ctoth@magnus.acs.ohio-state.edu (Christopher M Toth) Subject: Odd Virus? HELP (PC) Before backing up my hard drive last friday, I ran NAV to make sure I wasn't going to make backup copies of any virus. NAV told me that it had detected the Pakistani virus and another one called the Brain virus. First of all, I thought the Pakistani virus was only a floppy disk infector. Anyway, I exited NAV after the warning and tired using NAV again as a second check, well, this time NAV comes up with NO viruses on my hard drive. But when I checked my directory, I noticed that some of my files(50-60%) had their dates changed to dates ranging from 1955 to 1965. Can anyone help me out here?? Thanks!! - -Chris - -- Christopher M. Toth | "... We travel in the dark of a new moon The Ohio State University | A starry highway traced on the map of the sky Columbus State | Like lovers and heroes, CIS/History/Classics/ect..Major | Lonely as the eagle's cry..." -Peart ------------------------------ Date: 05 Dec 92 20:16:00 +0000 >From: @fuug.fi:kari.laine@compart.fi (Kari Laine) Subject: Not a stupid OS/2 Question (OS/2) To straighten things up. S&S International Ltd. IS shipping an OS/2 version of Toolkit. Actually they have been doing it for some time now. And guess what - it even works (heh). Kari Laine ------------------------------ Date: Sun, 06 Dec 92 21:53:54 +0000 >From: vess@Cadence.COM (Vess Kavalov) Subject: Re: ViruScan v99 and OS/2 (OS/2) Brian_Hampson@f115.n101.z9.virnet.bad.se (Brian Hampson) writes: >There is an apparent problem with SCAN 9.0V99 running in a DOS session >under OS/2 using HPFS file system > >Here is what it reported: > >- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > >C:\>scan d: /nomem >SCAN 9.0V99 Copyright 1989-92 by McAfee Associates. (408) 988-3832 >Scanning for known viruses. > > >Sorry, I can't scan drive d:! > > No viruses found. > >C:\>scan c: /nomem >SCAN 9.0V99 Copyright 1989-92 by McAfee Associates. (408) 988-3832 >Scanning for known viruses. > > >Sorry, I can't scan drive c:! > > No viruses found. >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >It can't FIND my Hard Disks...disconcerting. > >Here, on the OTHER hand, is what scan97B reported: > >- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >C:\>scan97 d: /nomem >SCAN 8.9B97 Copyright 1989-92 by McAfee Associates. (408) 988-3832 >Scanning for known viruses. > >Scanning Volume: DDRIVE > >Disk D: contains 28 directories and 696 files. > > No viruses found. > >C:\>scan97 c: /nomem >SCAN 8.9B97 Copyright 1989-92 by McAfee Associates. (408) 988-3832 >Scanning for known viruses. > >Scanning Volume: OS2 >Disk C: contains 119 directories and 2827 files. > > No viruses found. With me this happens only on HPFS partitioned volumes Anyway, they have SCAN for os/2 (beta) and it seems to work fine with me. There is just one problem - it hangs from time to time when you scan your system volume, but they ensured me that this problem has been fixed already though not released yet. (Let us hope it will happen soon.) Regards. ------------------------------ Date: Sun, 06 Dec 92 21:55:36 +0000 >From: vess@Cadence.COM (Vess Kavalov) Subject: Re: Potentially stupid question (OS/2) (PC) KDC@ccm.UManitoba.CA (Ken De Cruyenaere 204-474-8340) writes: >I am not too familiar with OS/2 but am told its going to be very >popular soon :-(. >Our antiviral software (F-PROT) doesn't seem to run well under OS/2. > (It eventually hangs up when scanning, saying > "ERROR SCANNING DRIVE D:") > > McAfee SCAN (V99) apparently gets the same results. > >My question: > What are people running OS/2 using/running as anti-viral software? Well , I use SCAN for os/2. ------------------------------ Date: Sun, 06 Dec 92 07:04:19 -0500 >From: fc@turing.duq.edu (Fred Cohen) Subject: FC on virus creation I am surprised that so many well respected Virus-L readers and writers failed to understand the implication of creating 1500 viruses per day that are not detected by existing scanners. The point is that the number or percentqge of viruses detected is not as important as the eff of the product. Of the CARO collection of over 1500 viruses, only a small portion have ever been found at a substantial number of sites, and many are collector-only viruses that have never appeared in the wild. I am quite astounded by the concept that creating viruses in the privacy of my home should offend anti-virus types. In fact, I have had automated virus generation systems running for several years. At one point, I was trying to create ecosystems by randomly generating tens of thousands of candidates per day, many of which were successful viruses. Why does this offend other researchers? And I take it from some of the comments that these researchers have NEVER created a virus of their own to explore the concept! It's sad that people who have never tried it feel free to condemn it. Or have they done it and simply don't have the integrity to admit it? ASP has already introduced one virus-based commercial product (which has never been detected as a virus by any scanner) which operates quite well, and we are in the process of creating another virus-based product designed to operate in LANs. Our users don't seem to be offended by the optimization of resource utilization, automated distribution and installation, high reliability, and small space used by our products based on viruses, but it seems to offend the anti-virus community that all of their overblown claims about all viruses being bad are being undercut by benevolent viruses that are safe and reliable. In fact, most of our viruses work on far more systems than most virus defenses, and they don't spread where they are not supposed to go. They are easy to control and remove, they are compatable with every DOS based system we have seen to date, and they have never generated any unintended side-effects. Kinda blows the whole "all viruses are bad" thing, huh! NEW PRODUCT ANOUNCEMENT - BENEVOLENT VIRUSES IN LANS AUTOMATE MUCH OF LAN MANAGEMENT - ANTI-VIRUS COMMUNITY SHUDDERS - SCANNER PRODUCTS MUST ADAPT TO DIFFERENTIATE BETWEEN KNOWN GOOD VIRUSES AND VARIENTS CREATED BY BAD VIRUS WRITERS - FOR DETAILS CONTACT ASP p.s. considering the people who agree with my recent postings, I may have been wrong - nah - you know you're not saying much when everyone agrees with you - the lemmings to the sea thing and all. FC ------------------------------ Date: 07 Dec 92 13:12:45 -0500 >From: "Ross M. Greenberg" <72461.3212@CompuServe.COM> Subject: Re: Integrity Management >Date: Wed, 02 Dec 92 13:41:35 -0500 >From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) >...Have just noticed that one of the major anti-virus houses has completed >the addition of effective integrity management with the ability to >use a single file for storage of all data for checking by their TSR >instead of relying on snippets on the end of each program. C'mon now, Padgett: my own Virex-PC code has had this ability for something like two years. Heck, even Flu_Shot+ has had that since Day One (well, since version 1.1, at least) which means that it's been available for about four years by this time... Ross ------------------------------ Date: 07 Dec 92 23:13:05 +0000 >From: ygoland@edison.SEAS.UCLA.EDU (The Jester) Subject: Re: Second generation problems (Philosophy) padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) writes: >Second generation problems are the ones that only become apparent when >a "fix" for the first generation problem is applied e.g. Some BIOSes >allow selection of C: as the boot drive. Sometimes you *want* to boot >from A: (to remove disk cacheing so that disk defragmentation can take >place) but do not want to change the CMOS & boot several times to do >so. I think we can cut off your problem at the pass. Its a matter of the greatest good for the greatest number. Most people do not ever need to boot from the A drive, the exception being when their system crashes. Since this is hopefully rare, having to go into the CMOS to change the boot from C to A (which itself should be rare since the system is supposed to be smart enough to know that it can't boot from the crashed C drive) isn't that big a deal. Now there are certain people, who for a variety of reasons, do need to boot from disk on a fairly regular basis. From a security point of view the gate is already open. Giving them a button to press (in the case of having a key based override to boot from A instead of C) or just automatically booting from A isn't really a big difference. Its the floppy itself that is the problem. For the minority of the people who actually need to boot from floppy, I would recomend they just set their system to boot from A and make sure there aren't any disks in the disk drive that they don't already know about. Yaron (The Jester) Goland - -- The Jester "Freedom isn't Free"-The U.S. Army "Nothing is too wonderful to be true"-Faraday "If I knew it all, what would I be doing HERE?"-The Jester ------------------------------ Date: 07 Dec 92 06:41:08 +0000 >From: ygoland@edison.SEAS.UCLA.EDU (The Jester) Subject: A user's view of IBM's antivirus/2 (OS/2) NOTE:The following review does NOT judge the virus detecting abilities of antivirus/2. I do not have sufficent time and resources to do this sort of testing. Hopefully Vessilin will do this as he is the only source I would trust. A User's View of IBM's antivirus/2 This product is a big leap in the right direction, unfortunatly it lept so far it fell over the edge. The program tries to make virus detection and handling as painless as possible. It's features include an automated checking utility that lets you set a daily, weekly, monthly, one time, or only on bootup, setting to run a virus check. The virus checker has a full range of options for choosing which files to check. In addition the virus checker maintains an integredity database, so you can choose to only check files which have been altered. In addition, once your options are set, activating a virus check manually is very easy. The virus program screen has a nice big button in the middle marked "Check for viruses". In addition the standard set up codes are good and when installed (a truly painless process) the program will automatically do the first system check. The manuals say that the program uses straight scanning, fuzzy scanning (where codes simliar to the ones in the database are looked for), Heurisitic Scanning (method is unspecified), and integrity management. Exactly what information is recorded about a file is unclear but I took my hex viewer and examined their database file. It has the names of all the files checked (which in my case is well over 3000) in an unencrypted and very orderly format, the information kept on each file is only a couple bytes and I was able to determine that it includes the file size. I don't know if it is using any sort of checksum in addition to this, but whatever the file is recording its very very orderly. This means that a directed attack should have an EXCELLENT chance of working. Besides the fact that the database file is unencrypted, another complaint I have regarding the integrity management is that unlike my favorite integrity manager, Integrity Master by Wolfgang Stiller, this program does not list all files that have changed and how they have changed. (On a related note, if Stiller had made an OS/2 version of his program, I wouldn't have had to buy IBM's) I have a feeling the reason this wasn't done was to make the program 'more friendly'. However IBM shot itself in the foot. Right now when you run a virus check you only get a message if something goes wrong, nothing else shows up. Thats great! In addition, a file is created everytime you do a check listing specifics of how the search was done and any interesting things that might have happened (such as being unable to open a file). This file is easy to reach from within the viral program and only people who care need look at it. If IBM had just added a list of changed files, I wouldn't be complaining. In conclusion, IBM's AntiVirus/2 is the friendliest anti-viral program I have seen. Its easy to install, set up, and use. But it's integrity Management features leave alot to be desired. Yaron (The Jester) Goland - -- For some reason unintelligible to me, Lord Acton's dictum that "Power tends to corrupt and absolute power corrupts absolutely" is rarely raised in connection with judges, who...possess power .that comes [close] to being absolute"-Judge Bork ------------------------------ Date: 06 Dec 92 17:33:38 +0000 >From: jay@info.umd.edu (Jay Elvove) Subject: Survey I hope I'm not out of line by posting this questionnaire to this group (I've already posted it to the Novell LISTSERV and have gotten a fair number of responses back). I am doing a study of computer viruses as part of a Masters management project and as background for a proposal I am developing for my employeer (the University of Maryland at College Park). I seek feedback from other organizations as to how they perceive the threat from computer viruses and what, if anything, they are doing about it. I would appreciate it more than I can say if you could take a few minutes to fill out the questionnaire and send it back to me via e-mail (fax and snail mail are ok, too). I hope to have the results tallied by the end of the year. I'd be delighted to share them with you. Simply attach a message so stating to your survey response. Please respond to me directly, not to this list. Thank you all very much, in advance Jay Elvove ----------cut here----------cut here----------cut here---------- Virus Questionnaire Please answer each of the following questions by circling the response (or placing an X to the immediate right of your choice if you are responding on-line), filling in the blank, or responding in full to the question, as appropriate. There are several questions whose answers depend on whether you are responding from a College/University (Coll/Univ) or a non-academic organization (non-acad). Please answer these question by selecting choices from the line that pertains most closely with your workplace. 1. How many PCs do you use or oversee? 1 2-4 5-9 10-19 20-49 50+ 2. Which of the following best describes your PC computing environment? standalone open lab restricted lab departmental LAN combination 3. Approximately what percent of the above computers are used by each of the following? Please choose your answers from one line only. (Coll/Univ) faculty staff grad student undergraduate other (non-acad) clerical accounting technical administrative other 4. In your opinion, how serious a threat do viruses pose to your computing environment? extreme very moderate little none 5. Within the last six months, how many incidents of computer viruses have you seen? 1 2-4 5-9 10-19 20-49 50+ none If the answer to the previous question was one or more, please answer the following four question: (a) What virus(es) have you seen? (b) What was the extent of the damage, if any? (c) How long did it take to remove or otherwise recover from the virus(es) (d) Which of the following groups has been the source of the greatest number of viruses? (Coll/Univ) faculty staff grad student undergraduate other (non-acad) clerical accounting technical administrative other 6. Whether or not your computer environment has been exposed to viruses in the past, in your opinion, which of the following groups is most likely to be a source of viruses within your environment today? (Coll/Univ) faculty staff grad student undergraduate other (non-acad) clerical accounting technical administrative other 7. In your opinion, how are computer viruses most likely to be transmitted? 8. Which regimen most closely approximates how often you scan your PC(s) for viruses? boot-up daily weekly monthly rarely never 9. How many of your PCs use TSR programs to detect viruses? 1 2-4 5-9 10-19 20-49 50+ none 10. How often do you back up your files? daily weekly monthly rarely never 11. What procedures are in place in your environment to address the threat of viruses (i.e., regular scanning, using TSR programs, backing up files, user education, official policies, etc.)? Please list specific anti-virus products in use. 12. Which best describes your role within your organization? (Coll/Univ) faculty staff grad student undergraduate other (non-acad) clerical accounting technical administrative other ------------------------- Please attach a separate sheet if you would like to provide further comments. If you would be willing to answer additional questions in person or by phone, or if you would like me to get back to you regarding your comments, please let me know. Be sure to include your name and phone number. Please return the survey to: Jay Elvove c/o Academic Software Computer Science Center phone: (301)403-4608 University of Maryland fax: (301)403-4628 College Park, MD 20742-2411 email: jay@info.umd.edu Thank you very much for your help with this survey. - -- Jay Elvove jay@info.umd.edu c/o Academic Software Comp. Sci. Center, Univ. of Md., College Park ------------------------------ Date: Sat, 05 Dec 92 12:37:26 -0500 >From: mcafee@netcom.com (McAfee Associates) Subject: CLEAN-UP, VSHIELD, & WSCAN 99 uploaded to Simtel20 (PC) I have uploaded to WSMR-SIMTEL20.Army.Mil: pd1: CLEAN99.ZIP CLEAN-UP V99 virus disinfector VSHLD99.ZIP VSHIELD V99 virus prevention TSR WSCAN99.ZIP WSCAN V99 VIRUSCAN for Windows 3.x WHAT'S NEW Version 99 of the VIRUSCAN (SCAN, CLEAN, NETSCAN, VSHIELD, and WSCAN) series of programs adds detection of 90 new viruses, bringing the total to 865 viruses, or counting variants, 1561. WSCAN has been updated to reflect the new /AD (scan all local drives) switch added in VIRUSCAN. VSHIELD has one new option added, the /CF {filename} switch. When run with this switch, VSHIELD will check files for unknown viruses using a recovery & validation data file created by VIRUSCAN. Thanks to Martin Kiff for this suggestion. CLEAN-UP has new disinfectors added for the Ontario, Tabulero, Walkabout, Npox 2.0, and Npox 2.1 viruses, as well as a new remover for the FORM virus. The VIRUSCAN and NETSCAN programs are already available from this site so they have not been sent a second time. Version 98 was skipped because of a report of a Trojan horse from San Francisco, Calif. VALIDATION DATA FOR THE VIRUSCAN V99 PROGRAMS Following is the validation data for the various programs. Please remember that I send these programs directly to the WSMR-SIMTEL20.Army.Mil and garbo.uwasa.fi sites directly by myself. If you download the programs from either site, or from any site that mirrors them, there is no need to worry about tampering. CLEAN-UP V99 (CLEAN.EXE) S:110,878 D:12-01-92 M1: 1477 M2: 1D5F NETSCAN V99 (NETSCAN.EXE) (not released on Internet) NETSCAN B99 (NETSCAN.EXE) S:84,181 D:11-17-92 M1: 9701 M2: 07AB SCAN FOR WINDOWS V99 (WINSTALL.EXE) S:15,575 D:11-23-92 M1: 5D84 M2: 1892 SCAN FOR WINDOWS V99 (WSCAN99.EXE) S:90,238 D:11-23-92 M1: 8C0D M2: 09D2 VIRUSCAN SCANV99 (SCAN.EXE) S:86,205 D:11-16-92 M1: 843C M2: 16E0 VSHIELD VSHLD99 (VSHIELD.EXE) S:45,576 D:12-01-92 M1: B7EE M2: 037E Regards, Aryeh Goretsky McAfee Associates Technical Support - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - McAfee Associates, Inc. | Voice (408) 988-3832 | INTERNET: 3350 Scott Blvd, Bldg 14 | FAX (408) 970-9727 | mcafee@netcom.COM Santa Clara, California | BBS (408) 988-4004 | CompuServe ID: 76702,1714 95054-3107 USA | USR HST Courier DS | or GO MCAFEE Support for SENTRY/SCAN/NETSCAN/VSHIELD/CLEAN/WSCAN/NETSHIELD/TARGET/CONFIG MGR ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 199] Downloaded From P-80 International Information Systems 304-744-2253