Info-PGP: PGP Digest Thursday 26 November 1992 Volume 1 : Number 34 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(1) ------------------------------------------------------------------------------- Newsgroups: alt.security.pgp From: vatne@alcatel.no (Lars Vatne) Subject: Re: How secure is "casual" or "military"? Date: Thu, 19 Nov 92 10:16:09 GMT In article <1992Nov17.123738.9570@u.washington.edu>, snark@blegga.u.washington.edu (David Howell) writes: |> |> How secure ARE the various sizes? "Casual" eh? I mean, exactly, |> approximately, or even vaguely how much time, talent, and/or computer |> power would be needed to crack a pgp encryption? I've got enough |> computer power that a 1024-bit key doesn't take that long to work, |> and I'm sure it'll only get faster for all of us. I'm assuming that a |> 1K key is more than merely twice as hard to open (at least with brute |> force) than a 512-bit key, yes? Quoting from "Security mechanisms for computer networks", Sead Muftic et al, Ellis Horwood 1989: Magnitude for the modulus in the RSA system ----------------------------------------------------------------------- Log10(n) Number of operations Remarks ----------------------------------------------------------------------- 50 1.4E10 100 2.3E15 At the limits of current technology 200 1.2E23 Beyond current technology 400 2.7E34 Requires significant advances in technology 800 1.3E51 Provided you have a 10 000 MIPS computer system (which you don't), you'd use ~ 3E33 years factoring the primes for an 800 bit modulo. Need a lot of patience.... -- Lars Vatne Phone : +47 2 63 76 51 Engineering Division Fax : +47 2 63 84 97 Alcatel Telecom Norway AS e-mail : lars.vatne@alcatel.no =-=-=-=-=-= From: ujacampbe@memstvx1.memst.edu (James Campbell) Newsgroups: alt.security.pgp Subject: Re: How secure is "casual" or "military"? Date: 19 Nov 92 12:03:29 -0600 In article <1992Nov19.101609.9113@alcatel.no>, Lars Vatne writes: > Provided you have a 10 000 MIPS computer system (which you don't), you'd > use ~ 3E33 years factoring the primes for an 800 bit modulo. Need a lot of > patience.... But log10(2^800) = 240.824, not 800. It would take a 2658-bit modulus to get a log10 of 800. Since PGP 2.0 only allows RSA keys up to a size of 1136 bits, the largest possible PGP key has a log10(2^1136) of 341.97, for which factoring would require around 2.5E31 operations, according to your source. Also, this is a three-year-old UNCLASSIFIED document that you quote. It's reasonable to assume that some large black-budgeted cryptologic organization (for example, our NSA here in America) has better factoring algorithms than are generally available, considering that they are better-funded and driven by their mission to produce and use the fastest algorithms possible. =========================================================================== James Campbell, Math Sciences Department, MSU; ujacampbe@memstvx1.memst.edu --------------------------------------------------------------------------- =-=-=-=-=-= Newsgroups: alt.security.pgp From: hmiller@lucpul.it.luc.edu (Hugh Miller) Subject: PGP 2.0 sites list Date: Sun, 22 Nov 1992 19:12:56 GMT (Last modified: 1850 UTC, 22 Nov 92) PGP v. 2.0 is gradually making its way out into the electronic world. It has been posted to the FidoNet Software Distribution Network and should up on many if not most Canadian and U.S. nodes carrying SDN software. Sorry: not on FidoNet nodes outside the U.S. or Canada yet; U.S. crypto export laws are strict and their enforcement is humorless. (Odd that U.S. export laws treat Canada as part of the U.S., eh? Jumping the gun by a few years there, aren't we?) Look for a local node near you. On the Internet, there are many sites to try for anonymous ftp: nic.funet.fi (128.214.6.100) /pub/unix/security/crypt/pgp20.zip /pub/unix/security/crypt/pgp20src.zip van-bc.wimsey.bc.ca (192.48.234.1) /pub/crypto/PGP-2.0/pgp20.zip /pub/crypto/PGP-2.0/pgp20src.zip ftp.uni-kl.de (131.246.9.95) /pub/atari/incoming/pgp20.zip (Atari binary) /pub/atari/incoming/pgp20src.zip ghost.dsi.unimi.it (149.132.2.1) /pub/crypt/pgp20.zip /pub/crypt/pgp20src.zip gate.demon.co.uk (158.152.1.65) /pub/ibmpc/pgp/pgp20.zip qiclab.scn.rain.com (147.28.0.97) /pub/mail/pgp20.zip pc.usl.edu (130.70.40.3) /pub/msdos/crypto/pgp20.zip leif.thep.lu.se (130.235.92.55) /pub/Misc/pgp20.zip goya.dit.upm.es (138.4.2.2) /info/unix/misc/pgp20/pgp20.zip tupac-amaru.informatik.rwth-aachen.de (137.226.112.31) /pub/rz.archiv/simtel/msdos/MSDOS_UPLOADS/pgp20.zip ftp.etsu.edu (192.43.199.20) /aminet/util/crypt/PGP20amiga.lha (Amiga binary) princeton.edu (128.112.128.1) /pub/pgp20/pgp20.zip /pub/pgp20/unix_pgp20.tar.Z (compressed tar file for Unix sites lacking an implementation of unzip.) pencil.cs.missouri.edu (128.206.100.207) /pub/crypt/pgp20.zip /pub/crypt/pgp20src.zip /pub/crypt/pgp20src.tar.Z (compressed tar file for Unix sites lacking an implementation of unzip.) 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/pgp20src.zip SEND pub/unix/security/crypt/pgp20.zip This will deposit the two zipfiles, as 15 batched messages, in your mailbox with about 24 hours. Save and uudecode. You can try to get PGP 2.0 via email from: listserv@spectrx.saigon.com Send a statement: /PDGET /public/msdos/pgp20.zip [UUENCODE | XXENCODE] This is a small DOS Waffle machine in San Jose, CA (not Vietnam). PGP20.ZIP is available in the UNIX and IBMPC RoundTables on the commercial service, GEnie. Search for "PGP" or "Privacy" or for uploads by "ANDY" (Andy Finkenstadt, GEnie UNIX sysop/manager, to whom many thanks!) Both PGP20.ZIP and PGP20SRC.ZIP are available from Exec-PC in Milwaukee, one of (if not *the*) largest private BBS's in North America. They're available in the Mahoney IBM Compatible MS-DOS collection. The 2400b number there is (414)789-4210. From there it should spread pretty rapidly across the BBS landscape of the U.S. and Canada, parallelling the FidoNet diffusion. Both PGP zipfiles have also been uploaded to BIX (Byte Information Exchange). To download them: After signon, type "LISTINGS" Select option "1" (category) Type "SECURITY" Select option "6" (download) Type "PGP20.ZIP" (or "PGP20SRC.ZIP") The Northern Lights BBS in Troy, NY, has both PGP20.ZIP and the source code, renamed to pgp20src.tar.Z for compatibility with Unix, 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 John Eichler in Little Rock. He 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 PGP20, 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. > > pgp20.zip > pgp20src.zip > pgp20os2.zip > pkz110.exe > > 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! Good news! PGP has been ported to the Apple Macintosh (a nontrivial feat)! The following note is from Zig Fiedorowicz, the implementer: "A Macintosh port of PGP 2.0 has been placed in the /mac/util/encryption directory of mac.archive.umich.edu. It has a modest Macintosh interface. It has not been tested extensively and should be considered a beta version. Bug reports are welcome. More work on MacPGP is planned and later versions will be more widely distributed." --Zig Fiedorowicz (zigf@mps.ohio-state.edu) The Mac version has also been posted at the following sites: plaza.aarnet.edu.au /micros/mac/umich/util/encryption/macpgp2.0.sit.hqx pencil.cs.missouri.edu /pub/crypt/macpgp2.0.sit.hqx wuarchive.wustl.edu /mirrors3/archive.umich.edu/mac/util/encryption/macpgp2.0.sit.hqx src.doc.ic.ac.uk /computing/systems/mac/umich/util/encryption/macpgp2.0.sit.hqx.Z 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! P.P.S.: This will be the last revision of the sites message until the appearance of version PGP 2.1, expected sometime in the next few weeks. -- Hugh Miller | Dept. of Philosophy | Loyola University of Chicago Voice: 312-508-2727 | FAX: 312-508-2292 | hmiller@lucpul.it.luc.edu =-=-=-=-=-= Newsgroups: alt.security.pgp From: cbbrowne@csi.uottawa.ca (Christopher Browne) Subject: Re: PGP 2.0 sites list Date: Sun, 22 Nov 92 22:55:11 GMT In article hmiller@lucpul.it.luc.edu (Hugh Miller) writes: >many if not most Canadian and U.S. nodes carrying SDN software. >Sorry: not on FidoNet nodes outside the U.S. or Canada yet; U.S. >crypto export laws are strict and their enforcement is humorless. >(Odd that U.S. export laws treat Canada as part of the U.S., eh? >Jumping the gun by a few years there, aren't we?) Interestingly, the patent restrictions that could be of danger to users in the US seem not to apply in Canada. Canadians can't export PGP out of North America, but it does look like they can use it with relative impunity. >Look for a local node near you. On the Internet, there are many sites >to try for anonymous ftp: >... > ftp.uni-kl.de (131.246.9.95) > /pub/atari/incoming/pgp20.zip (Atari binary) > /pub/atari/incoming/pgp20src.zip This information is outdated; PGP is no longer available there. And pgp20.zip was actually the IBM binaries, and not the Atari version; it would be of great interest to ST users to find an actual site where TOS binaries are available. I've had it running under MiNT, and have had a number of requests for a TOS version, which I haven't been able to satisfy, due to a lack of debugging time as well as (in one case) export restrictions. Could someone from uni-kl (Stephen Neuhaus, perhaps?) see about publicising some German site where binaries are available? 'Twould be greatly appreciated! -- Christopher Browne | PGP 2.0 key available cbbrowne@csi.uottawa.ca |=================================== University of Ottawa | The Personal Computer: Colt 45 Master of System Science Program | of the Information Frontier =-=-=-=-=-= From: dswartz@sw.stratus.com (Dan Swartzendruber) Newsgroups: alt.security.pgp Subject: MacPgp Date: 21 Nov 92 19:42:52 GMT I'm a little confused on how to get this to work. When I try to create a key, it asks me some questions and then finally tells me it's going to generate a key by timing my typing of random characters and I should stop when I hear the beep. There are a couple of problems: 1. If I try to type at anything more than a trivial speed, the keystrokes are rejected with the system beep. 2. It doesn't ever seem to terminate. I've left it sitting there waiting for 5 minutes with no change. Am I missing something? -- #include Dan S. =-=-=-=-=-= From: fiedorow@function.mps.ohio-state.edu (Zbigniew Fiedorowicz) Newsgroups: alt.security.pgp Subject: Re: MacPgp Date: 23 Nov 1992 12:00:44 -0500 dswartz@sw.stratus.com (Dan Swartzendruber) writes: >I'm a little confused on how to get this to work. When I try to create a key >............................................................................. >of random characters and I should stop when I hear the beep. I'm the author of MacPGP and am sorry for the confusion. The above message is inaccurate. You should continue typing until PGP writes the following message to the console: -Enough, thank you. I am using the portable code to measure keystroke timing, which is inadequate to keep up with a good touch typist. So you must type a lot (>4 full lines) and slowly to generate enough random data for a 1024 bit key. Moreover once you finish typing enough characters, depending on your hardware, it will take a long to LONG time to actually generate a key. On a Quadra it will probably take <10 minutes, whereas on a Mac Plus it may take several hours for a 1024 bit key. During the period when MacPGP is computing a key (but not when timing keystroke intervals) MacPGP calls WaitNextEvent repeatedly to allow you to switch PGP to the background or to cancel key generation with command-period. I am planning to improve some of these aspects of MacPGP's performance in a forthcoming version. Cheers, Zig Fiedorowicz =-=-=-=-=-= Newsgroups: alt.security.pgp From: ematias@explorer.dgp (Edgar Matias) Subject: Re: MacPgp Date: 23 Nov 92 03:58:28 GMT I ftp'd MacPGP from mac.archive.umich.edu but couldn't get StuffIt Classic to unstuff it. Anyone else out there have a similar problem? Edgar -- Edgar Matias Input Research Group University of Toronto -- I speak for no one... =-=-=-=-=-= From: fiedorow@function.mps.ohio-state.edu (Zbigniew Fiedorowicz) Newsgroups: alt.security.pgp Subject: Re: MacPgp Date: 23 Nov 1992 12:09:08 -0500 Edgar Matias (ematias@explorer.dgp) writes: >I ftp'd MacPGP from mac.archive.umich.edu but couldn't get StuffIt Classic >to unstuff it. Anyone else out there have a similar problem? That's because MacPGP is compressed using the latest Stuffit compression scheme, unknown to Stuffit Classic. Get Stuffit Expander from any of the standard mac ftp archives. Cheers, Zig Fiedorowicz =-=-=-=-=-= Newsgroups: alt.security.pgp From: tcmay@netcom.com (Timothy C. May) Subject: Re: MacPgp Date: Mon, 23 Nov 1992 07:27:01 GMT Edgar Matias (ematias@explorer.dgp) wrote: : : I ftp'd MacPGP from mac.archive.umich.edu but couldn't get StuffIt Classic : to unstuff it. Anyone else out there have a similar problem? : I had the same problems--I first ran BinHex 5.0 (to convert the .hqx file to a .sit file) and then tried to unstuff it. It wouldn't even show up in StuffIt's file selection menu. Then I tried BinHex 4.0 and UnstuffIt and it all worked. I suspect it was the BinHex 4.0 that made the difference. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement. =-=-=-=-=-= From: nonsenso@utopia.hacktic.nl (Felipe Rodriquez) Newsgroups: alt.security.pgp Subject: PGP 2.0 sites-list Date: Mon, 23 Nov 92 19:40:12 GMT > PGP v. 2.0 is gradually making its way out into the electronic world. It >has been posted to the FidoNet Software Distribution Network and should up on >many if not most Canadian and U.S. nodes carrying SDN software. Sorry: not on >FidoNet nodes outside the U.S. or Canada yet; U.S. crypto export laws are >strict and their enforcement is humorless. (Odd that U.S. export laws treat >Canada as part of the U.S., eh? Jumping the gun by a few years there, aren't >we?) Look for a local node near you. On the Internet, there are many sites >to try for anonymous ftp: I have personally uploaded the PGP sdn package to all european SDM backbones. It should have been distributed through the SDN network here, as it was in the states. This was 2 months ago :-) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqrg5sAAAEEANyzAvOLI+VZYd5hen0Lme/eyasVrZVLMLYU7vvKTq6GIwtE Rypu9aZyEAVE6hy896JLR58IxYDVRCwY7Bwcp9sFdoTPXDrEEcSkA3Vdt5uiQh5u h7nfRXG9rVEcw9FYKHkvbPZMNfRVW71hKlZM+QweHNcFYsyz+TjMMcKgfAL5AAUR tC1GZWxpcGUgUm9kcmlxdWV6IDxub25zZW5zb0B1dG9waWEuaGFja3RpYy5ubD4= =q/if =-=-=-=-=-= Newsgroups: alt.security.pgp From: neuhaus@vier.informatik.uni-kl.de (Stephan Neuhaus (HiWi Mattern)) Subject: Re: PGP 2.0 sites list Date: Tue, 24 Nov 1992 14:33:26 GMT cbbrowne@csi.uottawa.ca (Christopher Browne) writes: >In article hmiller@lucpul.it.luc.edu (Hugh Miller) writes: >>Look for a local node near you. On the Internet, there are many sites >>to try for anonymous ftp: >>... >> ftp.uni-kl.de (131.246.9.95) >> /pub/atari/incoming/pgp20.zip (Atari binary) >> /pub/atari/incoming/pgp20src.zip >This information is outdated; PGP is no longer available there. And >pgp20.zip was actually the IBM binaries, and not the Atari version; Right, I just looked. I don't know what has happened to them; I guess they just got deleted. Somehow I nuked my copy of pgp20src.zip, but I still have a homemade pgp-2.0.tar.Z and pgp20.zip. These contain, as you said, the MSDOS binaries. I would like to create a TOS version (as compared to a MiNT version) but I have recently bought a SUN 3 and needed a hard disk... Therefore: No development on or for the ST anymore. I only have my own Atari executable, which runs under MiNT. >Could someone from uni-kl (Stephen Neuhaus, perhaps?) see about >publicising some German site where binaries are available? 'Twould be >greatly appreciated! Hmmm... Without archie to help, this task is beyond my means. And I have already received requests from Germans who couldn't get a TOS version. If any of you have any ideas, please drop me a note and I'll see what I can do. On top of my head, I don't know any archive sites with pure TOS binaries. For the moment, I'll upload the MSDOS binaries and Unix-style sources (ASCII 10 newline delimiters instead of ASCII 13/10) pgp-2.0.tar.Z into pub/atari/incoming again. This time, I'll notify the ftp admin, promise... :-) Tomorrow, I'll also upload the MiNT binary into the same directory. So, if you need either Unix-style sources, MSDOS executables, or MiNT executables, ftp to ftp.uni-kl.de and look in pub/atari/incoming for anything that begins with pgp. Note: The Atari subdirectory and its subdirectories are world writable. If I have the time, I'll compute a signature and any sufficiently paranoid signature can get it from me, either on paper, by voice or (least secure) by email. Have fun. -- Stephan sig closed for inventory. Please leave your pickaxe outside. PGP 2.0 public key available on request. Note the expiration date. =-=-=-=-=-= Newsgroups: alt.security.pgp From: neuhaus@vier.informatik.uni-kl.de (Stephan Neuhaus (HiWi Mattern)) Subject: Re: PGP 2.0 sites list Date: Tue, 24 Nov 1992 16:05:29 GMT neuhaus@vier.informatik.uni-kl.de (Stephan Neuhaus (HiWi Mattern)) writes: >If I have the time, I'll compute a signature and any >sufficiently paranoid signature can get it from me, either on paper, >by voice or (least secure) by email. What in hell was I thinking when I wrote about a ``sufficiently paranoid signature''? I meant ``sufficiently paranoid person'', of course! I had intended to be funny, and funny I was, even beyond my wildest dreams! >Have fun. That still holds, especially after reading this particularly delightful typo. Have fun. -- Stephan sig closed for inventory. Please leave your pickaxe outside. PGP 2.0 public key available on request. Note the expiration date. =-=-=-=-=-= Newsgroups: alt.security.pgp From: whitaker@eternity.demon.co.uk (Russell Earl Whitaker) Subject: Re: PGP 2.0 sites list Date: Mon, 23 Nov 1992 21:00:16 +0000 Also add to your list: /pub/ibmpc/pgp/pgp20.zip at gate.demon.co.uk -- Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= =-=-=-=-=-= From: mathew Newsgroups: alt.security.pgp Subject: Re: MacPgp Date: Wed, 25 Nov 92 17:01:49 GMT dswartz@sw.stratus.com (Dan Swartzendruber) writes: > 1. If I try to type at anything more than a trivial speed, the keystrokes are > with the system beep. Yes. Type VERY VERY SLOWLY. > 2. It doesn't ever seem to terminate. I've left it sitting there waiting for > with no change. Yup. It took ages on my Mac too. If you're running it on a Powerbook, as I was, make sure your Powerbook doesn't go into "power save" mode, which slows the machine down to 1/8 of the normal speed. > Am I missing something? Yes. MacPGP is VERY VERY SLOW. It took it several minutes to read my keyfile from my PC at work. I can easily believe that it takes more than five minutes to generate a key. Be careful when typing your password in, too. The program only seems to be able to cope with about two keystrokes per second. mathew =-=-=-=-=-= Newsgroups: alt.security.pgp,sci.crypt From: hmiller@lucpul.it.luc.edu (Hugh Miller) Subject: PGP vs. RIPEM Date: Thu, 26 Nov 1992 05:44:45 GMT 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. Some examples of how this influences their conceptual design follow. PEM integrates much of the cryptographic information into Internet style headers; PGP uses a more compact and efficient system-independent binary packet data structure. PEM's email-plus design exposes more information for traffic analysis than does PGP's standalone design. A major point is that PEM has a quite different concept of "identity" than does pgp. A major concept in PEM is that an identity is a mailbox in the internet heirarchical form; keys are then certified (through a similar heirarchy of organizations propagating trust from on high) as being connected to this "mailbox identity". This design makes a lot of sense from the Internet sense (domain heirarchies being already integral to the Internet conceptual model). PGP follows a different drummer, with different strengths and weaknesses. The fundamental concept of identity is the keypair itself. This is sufficiently different to deserve some background. 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. 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. 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. 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. 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. 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. 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. This is a very important difference, much more than whether IDEA or DES is used for encryption (as these will change). PGP would lose a great deal if it were limited to Internet mail applications (conceptually). On the other hand, it loses some "application specific targeting" by not being limited to Internet mail. Each approach has its tradeoffs. PGP may nevertheless become more integrated with given mail software over time; it's not impossible to make it easier to use from within a given mail package, as easy as RIPEM even. Certainly, it will be much easier to migrate PGP into RIPEM's limited application scope than vice versa! Just don't ask for a "PEM compatible" form of PGP - it was designed for a different and larger scope; if you want PEM compatibility, use RIPEM or some other implementation. Implementing IDEA in RIPEM, or DES in PGP, wouldn't scratch the surface towards making them "compatible"; those are just details. The serious incompatibility is that they address different needs, and were both designed differently from the ground up so as to meet those needs. -- Zhahai Stewart - via ParaNet node 1:104/422 UUCP: !scicom!paranet!User_Name INTERNET: Zhahai.Stewart@f93.n104.z1.FIDONET.ORG ***** End Info-PGP Digest ***** From sbranch Thu Nov 26 17:32:42 1992 Return-Path: Received: by well.sf.ca.us (5.65c/SMI-4.1/well-921112-2) id AA05902; Thu, 26 Nov 1992 17:32:23 -0800 Date: Thu, 26 Nov 1992 17:32:23 -0800 From: Kim Clancy Message-Id: <199211270132.AA05902@well.sf.ca.us> To: aissecur Subject: pgpnewsletter >From hmiller@lucpul.it.luc.edu Thu Nov 26 00:38:42 1992 Return-Path: Received: from nkosi.well.sf.ca.us by well.sf.ca.us with SMTP (5.65c/SMI-4.1/well-921112-2) id AA13510; Thu, 26 Nov 1992 00:38:35 -0800 Received: from lucpul.it.luc.edu ([147.126.240.1]) by nkosi.well.sf.ca.us (5.65c/SMI-4.1/nkosi-921112-1) id AA22908; Thu, 26 Nov 1992 00:40:51 -0800 Received: by lucpul.it.luc.edu (5.57/Ultrix3.0-C) id AA03133; Thu, 26 Nov 92 02:40:40 -0600 Message-Id: <9211260840.AA03133@lucpul.it.luc.edu> Subject: Info-PGP v. 1 # 34 From: hmiller@lucpul.it.luc.edu Date: Thu, 26 Nov 92 2:40:39 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 Thursday 26 November 1992 Volume 1 : Number 34 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(1) ------------------------------------------------------------------------------- Newsgroups: alt.security.pgp From: vatne@alcatel.no (Lars Vatne) Subject: Re: How secure is "casual" or "military"? Date: Thu, 19 Nov 92 10:16:09 GMT In article <1992Nov17.123738.9570@u.washington.edu>, snark@blegga.u.washington.edu (David Howell) writes: |> |> How secure ARE the various sizes? "Casual" eh? I mean, exactly, |> approximately, or even vaguely how much time, talent, and/or computer |> power would be needed to crack a pgp encryption? I've got enough |> computer power that a 1024-bit key doesn't take that long to work, |> and I'm sure it'll only get faster for all of us. I'm assuming that a |> 1K key is more than merely twice as hard to open (at least with brute |> force) than a 512-bit key, yes? Quoting from "Security mechanisms for computer networks", Sead Muftic et al, Ellis Horwood 1989: Magnitude for the modulus in the RSA system ----------------------------------------------------------------------- Log10(n) Number of operations Remarks ----------------------------------------------------------------------- 50 1.4E10 100 2.3E15 At the limits of current technology 200 1.2E23 Beyond current technology 400 2.7E34 Requires significant advances in technology 800 1.3E51 Provided you have a 10 000 MIPS computer system (which you don't), you'd use ~ 3E33 years factoring the primes for an 800 bit modulo. Need a lot of patience.... -- Lars Vatne Phone : +47 2 63 76 51 Engineering Division Fax : +47 2 63 84 97 Alcatel Telecom Norway AS e-mail : lars.vatne@alcatel.no =-=-=-=-=-= From: ujacampbe@memstvx1.memst.edu (James Campbell) Newsgroups: alt.security.pgp Subject: Re: How secure is "casual" or "military"? Date: 19 Nov 92 12:03:29 -0600 In article <1992Nov19.101609.9113@alcatel.no>, Lars Vatne writes: > Provided you have a 10 000 MIPS computer system (which you don't), you'd > use ~ 3E33 years factoring the primes for an 800 bit modulo. Need a lot of > patience.... But log10(2^800) = 240.824, not 800. It would take a 2658-bit modulus to get a log10 of 800. Since PGP 2.0 only allows RSA keys up to a size of 1136 bits, the largest possible PGP key has a log10(2^1136) of 341.97, for which factoring would require around 2.5E31 operations, according to your source. Also, this is a three-year-old UNCLASSIFIED document that you quote. It's reasonable to assume that some large black-budgeted cryptologic organization (for example, our NSA here in America) has better factoring algorithms than are generally available, considering that they are better-funded and driven by their mission to produce and use the fastest algorithms possible. =========================================================================== James Campbell, Math Sciences Department, MSU; ujacampbe@memstvx1.memst.edu --------------------------------------------------------------------------- =-=-=-=-=-= Newsgroups: alt.security.pgp From: hmiller@lucpul.it.luc.edu (Hugh Miller) Subject: PGP 2.0 sites list Date: Sun, 22 Nov 1992 19:12:56 GMT (Last modified: 1850 UTC, 22 Nov 92) PGP v. 2.0 is gradually making its way out into the electronic world. It has been posted to the FidoNet Software Distribution Network and should up on many if not most Canadian and U.S. nodes carrying SDN software. Sorry: not on FidoNet nodes outside the U.S. or Canada yet; U.S. crypto export laws are strict and their enforcement is humorless. (Odd that U.S. export laws treat Canada as part of the U.S., eh? Jumping the gun by a few years there, aren't we?) Look for a local node near you. On the Internet, there are many sites to try for anonymous ftp: nic.funet.fi (128.214.6.100) /pub/unix/security/crypt/pgp20.zip /pub/unix/security/crypt/pgp20src.zip van-bc.wimsey.bc.ca (192.48.234.1) /pub/crypto/PGP-2.0/pgp20.zip /pub/crypto/PGP-2.0/pgp20src.zip ftp.uni-kl.de (131.246.9.95) /pub/atari/incoming/pgp20.zip (Atari binary) /pub/atari/incoming/pgp20src.zip ghost.dsi.unimi.it (149.132.2.1) /pub/crypt/pgp20.zip /pub/crypt/pgp20src.zip gate.demon.co.uk (158.152.1.65) /pub/ibmpc/pgp/pgp20.zip qiclab.scn.rain.com (147.28.0.97) /pub/mail/pgp20.zip pc.usl.edu (130.70.40.3) /pub/msdos/crypto/pgp20.zip leif.thep.lu.se (130.235.92.55) /pub/Misc/pgp20.zip goya.dit.upm.es (138.4.2.2) /info/unix/misc/pgp20/pgp20.zip tupac-amaru.informatik.rwth-aachen.de (137.226.112.31) /pub/rz.archiv/simtel/msdos/MSDOS_UPLOADS/pgp20.zip ftp.etsu.edu (192.43.199.20) /aminet/util/crypt/PGP20amiga.lha (Amiga binary) princeton.edu (128.112.128.1) /pub/pgp20/pgp20.zip /pub/pgp20/unix_pgp20.tar.Z (compressed tar file for Unix sites lacking an implementation of unzip.) pencil.cs.missouri.edu (128.206.100.207) /pub/crypt/pgp20.zip /pub/crypt/pgp20src.zip /pub/crypt/pgp20src.tar.Z (compressed tar file for Unix sites lacking an implementation of unzip.) 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/pgp20src.zip SEND pub/unix/security/crypt/pgp20.zip This will deposit the two zipfiles, as 15 batched messages, in your mailbox with about 24 hours. Save and uudecode. You can try to get PGP 2.0 via email from: listserv@spectrx.saigon.com Send a statement: /PDGET /public/msdos/pgp20.zip [UUENCODE | XXENCODE] This is a small DOS Waffle machine in San Jose, CA (not Vietnam). PGP20.ZIP is available in the UNIX and IBMPC RoundTables on the commercial service, GEnie. Search for "PGP" or "Privacy" or for uploads by "ANDY" (Andy Finkenstadt, GEnie UNIX sysop/manager, to whom many thanks!) Both PGP20.ZIP and PGP20SRC.ZIP are available from Exec-PC in Milwaukee, one of (if not *the*) largest private BBS's in North America. They're available in the Mahoney IBM Compatible MS-DOS collection. The 2400b number there is (414)789-4210. From there it should spread pretty rapidly across the BBS landscape of the U.S. and Canada, parallelling the FidoNet diffusion. Both PGP zipfiles have also been uploaded to BIX (Byte Information Exchange). To download them: After signon, type "LISTINGS" Select option "1" (category) Type "SECURITY" Select option "6" (download) Type "PGP20.ZIP" (or "PGP20SRC.ZIP") The Northern Lights BBS in Troy, NY, has both PGP20.ZIP and the source code, renamed to pgp20src.tar.Z for compatibility with Unix, 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 John Eichler in Little Rock. He 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 PGP20, 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. > > pgp20.zip > pgp20src.zip > pgp20os2.zip > pkz110.exe > > 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! Good news! PGP has been ported to the Apple Macintosh (a nontrivial feat)! The following note is from Zig Fiedorowicz, the implementer: "A Macintosh port of PGP 2.0 has been placed in the /mac/util/encryption directory of mac.archive.umich.edu. It has a modest Macintosh interface. It has not been tested extensively and should be considered a beta version. Bug reports are welcome. More work on MacPGP is planned and later versions will be more widely distributed." --Zig Fiedorowicz (zigf@mps.ohio-state.edu) The Mac version has also been posted at the following sites: plaza.aarnet.edu.au /micros/mac/umich/util/encryption/macpgp2.0.sit.hqx pencil.cs.missouri.edu /pub/crypt/macpgp2.0.sit.hqx wuarchive.wustl.edu /mirrors3/archive.umich.edu/mac/util/encryption/macpgp2.0.sit.hqx src.doc.ic.ac.uk /computing/systems/mac/umich/util/encryption/macpgp2.0.sit.hqx.Z 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! P.P.S.: This will be the last revision of the sites message until the appearance of version PGP 2.1, expected sometime in the next few weeks. -- Hugh Miller | Dept. of Philosophy | Loyola University of Chicago Voice: 312-508-2727 | FAX: 312-508-2292 | hmiller@lucpul.it.luc.edu =-=-=-=-=-= Newsgroups: alt.security.pgp From: cbbrowne@csi.uottawa.ca (Christopher Browne) Subject: Re: PGP 2.0 sites list Date: Sun, 22 Nov 92 22:55:11 GMT In article hmiller@lucpul.it.luc.edu (Hugh Miller) writes: >many if not most Canadian and U.S. nodes carrying SDN software. >Sorry: not on FidoNet nodes outside the U.S. or Canada yet; U.S. >crypto export laws are strict and their enforcement is humorless. >(Odd that U.S. export laws treat Canada as part of the U.S., eh? >Jumping the gun by a few years there, aren't we?) Interestingly, the patent restrictions that could be of danger to users in the US seem not to apply in Canada. Canadians can't export PGP out of North America, but it does look like they can use it with relative impunity. >Look for a local node near you. On the Internet, there are many sites >to try for anonymous ftp: >... > ftp.uni-kl.de (131.246.9.95) > /pub/atari/incoming/pgp20.zip (Atari binary) > /pub/atari/incoming/pgp20src.zip This information is outdated; PGP is no longer available there. And pgp20.zip was actually the IBM binaries, and not the Atari version; it would be of great interest to ST users to find an actual site where TOS binaries are available. I've had it running under MiNT, and have had a number of requests for a TOS version, which I haven't been able to satisfy, due to a lack of debugging time as well as (in one case) export restrictions. Could someone from uni-kl (Stephen Neuhaus, perhaps?) see about publicising some German site where binaries are available? 'Twould be greatly appreciated! -- Christopher Browne | PGP 2.0 key available cbbrowne@csi.uottawa.ca |=================================== University of Ottawa | The Personal Computer: Colt 45 Master of System Science Program | of the Information Frontier =-=-=-=-=-= From: dswartz@sw.stratus.com (Dan Swartzendruber) Newsgroups: alt.security.pgp Subject: MacPgp Date: 21 Nov 92 19:42:52 GMT I'm a little confused on how to get this to work. When I try to create a key, it asks me some questions and then finally tells me it's going to generate a key by timing my typing of random characters and I should stop when I hear the beep. There are a couple of problems: 1. If I try to type at anything more than a trivial speed, the keystrokes are rejected with the system beep. 2. It doesn't ever seem to terminate. I've left it sitting there waiting for 5 minutes with no change. Am I missing something? -- #include Dan S. =-=-=-=-=-= From: fiedorow@function.mps.ohio-state.edu (Zbigniew Fiedorowicz) Newsgroups: alt.security.pgp Subject: Re: MacPgp Date: 23 Nov 1992 12:00:44 -0500 dswartz@sw.stratus.com (Dan Swartzendruber) writes: >I'm a little confused on how to get this to work. When I try to create a key >............................................................................. >of random characters and I should stop when I hear the beep. I'm the author of MacPGP and am sorry for the confusion. The above message is inaccurate. You should continue typing until PGP writes the following message to the console: -Enough, thank you. I am using the portable code to measure keystroke timing, which is inadequate to keep up with a good touch typist. So you must type a lot (>4 full lines) and slowly to generate enough random data for a 1024 bit key. Moreover once you finish typing enough characters, depending on your hardware, it will take a long to LONG time to actually generate a key. On a Quadra it will probably take <10 minutes, whereas on a Mac Plus it may take several hours for a 1024 bit key. During the period when MacPGP is computing a key (but not when timing keystroke intervals) MacPGP calls WaitNextEvent repeatedly to allow you to switch PGP to the background or to cancel key generation with command-period. I am planning to improve some of these aspects of MacPGP's performance in a forthcoming version. Cheers, Zig Fiedorowicz =-=-=-=-=-= Newsgroups: alt.security.pgp From: ematias@explorer.dgp (Edgar Matias) Subject: Re: MacPgp Date: 23 Nov 92 03:58:28 GMT I ftp'd MacPGP from mac.archive.umich.edu but couldn't get StuffIt Classic to unstuff it. Anyone else out there have a similar problem? Edgar -- Edgar Matias Input Research Group University of Toronto -- I speak for no one... =-=-=-=-=-= From: fiedorow@function.mps.ohio-state.edu (Zbigniew Fiedorowicz) Newsgroups: alt.security.pgp Subject: Re: MacPgp Date: 23 Nov 1992 12:09:08 -0500 Edgar Matias (ematias@explorer.dgp) writes: >I ftp'd MacPGP from mac.archive.umich.edu but couldn't get StuffIt Classic >to unstuff it. Anyone else out there have a similar problem? That's because MacPGP is compressed using the latest Stuffit compression scheme, unknown to Stuffit Classic. Get Stuffit Expander from any of the standard mac ftp archives. Cheers, Zig Fiedorowicz =-=-=-=-=-= Newsgroups: alt.security.pgp From: tcmay@netcom.com (Timothy C. May) Subject: Re: MacPgp Date: Mon, 23 Nov 1992 07:27:01 GMT Edgar Matias (ematias@explorer.dgp) wrote: : : I ftp'd MacPGP from mac.archive.umich.edu but couldn't get StuffIt Classic : to unstuff it. Anyone else out there have a similar problem? : I had the same problems--I first ran BinHex 5.0 (to convert the .hqx file to a .sit file) and then tried to unstuff it. It wouldn't even show up in StuffIt's file selection menu. Then I tried BinHex 4.0 and UnstuffIt and it all worked. I suspect it was the BinHex 4.0 that made the difference. --Tim May -- .......................................................................... Timothy C. May | Crypto Anarchy: encryption, digital money, tcmay@netcom.com | anonymous networks, digital pseudonyms, zero 408-688-5409 | knowledge, reputations, information markets, W.A.S.T.E.: Aptos, CA | black markets, collapse of governments. Higher Power: 2^756839 | PGP Public Key: by arrangement. =-=-=-=-=-= From: nonsenso@utopia.hacktic.nl (Felipe Rodriquez) Newsgroups: alt.security.pgp Subject: PGP 2.0 sites-list Date: Mon, 23 Nov 92 19:40:12 GMT > PGP v. 2.0 is gradually making its way out into the electronic world. It >has been posted to the FidoNet Software Distribution Network and should up on >many if not most Canadian and U.S. nodes carrying SDN software. Sorry: not on >FidoNet nodes outside the U.S. or Canada yet; U.S. crypto export laws are >strict and their enforcement is humorless. (Odd that U.S. export laws treat >Canada as part of the U.S., eh? Jumping the gun by a few years there, aren't >we?) Look for a local node near you. On the Internet, there are many sites >to try for anonymous ftp: I have personally uploaded the PGP sdn package to all european SDM backbones. It should have been distributed through the SDN network here, as it was in the states. This was 2 months ago :-) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.0 mQCNAiqrg5sAAAEEANyzAvOLI+VZYd5hen0Lme/eyasVrZVLMLYU7vvKTq6GIwtE Rypu9aZyEAVE6hy896JLR58IxYDVRCwY7Bwcp9sFdoTPXDrEEcSkA3Vdt5uiQh5u h7nfRXG9rVEcw9FYKHkvbPZMNfRVW71hKlZM+QweHNcFYsyz+TjMMcKgfAL5AAUR tC1GZWxpcGUgUm9kcmlxdWV6IDxub25zZW5zb0B1dG9waWEuaGFja3RpYy5ubD4= =q/if =-=-=-=-=-= Newsgroups: alt.security.pgp From: neuhaus@vier.informatik.uni-kl.de (Stephan Neuhaus (HiWi Mattern)) Subject: Re: PGP 2.0 sites list Date: Tue, 24 Nov 1992 14:33:26 GMT cbbrowne@csi.uottawa.ca (Christopher Browne) writes: >In article hmiller@lucpul.it.luc.edu (Hugh Miller) writes: >>Look for a local node near you. On the Internet, there are many sites >>to try for anonymous ftp: >>... >> ftp.uni-kl.de (131.246.9.95) >> /pub/atari/incoming/pgp20.zip (Atari binary) >> /pub/atari/incoming/pgp20src.zip >This information is outdated; PGP is no longer available there. And >pgp20.zip was actually the IBM binaries, and not the Atari version; Right, I just looked. I don't know what has happened to them; I guess they just got deleted. Somehow I nuked my copy of pgp20src.zip, but I still have a homemade pgp-2.0.tar.Z and pgp20.zip. These contain, as you said, the MSDOS binaries. I would like to create a TOS version (as compared to a MiNT version) but I have recently bought a SUN 3 and needed a hard disk... Therefore: No development on or for the ST anymore. I only have my own Atari executable, which runs under MiNT. >Could someone from uni-kl (Stephen Neuhaus, perhaps?) see about >publicising some German site where binaries are available? 'Twould be >greatly appreciated! Hmmm... Without archie to help, this task is beyond my means. And I have already received requests from Germans who couldn't get a TOS version. If any of you have any ideas, please drop me a note and I'll see what I can do. On top of my head, I don't know any archive sites with pure TOS binaries. For the moment, I'll upload the MSDOS binaries and Unix-style sources (ASCII 10 newline delimiters instead of ASCII 13/10) pgp-2.0.tar.Z into pub/atari/incoming again. This time, I'll notify the ftp admin, promise... :-) Tomorrow, I'll also upload the MiNT binary into the same directory. So, if you need either Unix-style sources, MSDOS executables, or MiNT executables, ftp to ftp.uni-kl.de and look in pub/atari/incoming for anything that begins with pgp. Note: The Atari subdirectory and its subdirectories are world writable. If I have the time, I'll compute a signature and any sufficiently paranoid signature can get it from me, either on paper, by voice or (least secure) by email. Have fun. -- Stephan sig closed for inventory. Please leave your pickaxe outside. PGP 2.0 public key available on request. Note the expiration date. =-=-=-=-=-= Newsgroups: alt.security.pgp From: neuhaus@vier.informatik.uni-kl.de (Stephan Neuhaus (HiWi Mattern)) Subject: Re: PGP 2.0 sites list Date: Tue, 24 Nov 1992 16:05:29 GMT neuhaus@vier.informatik.uni-kl.de (Stephan Neuhaus (HiWi Mattern)) writes: >If I have the time, I'll compute a signature and any >sufficiently paranoid signature can get it from me, either on paper, >by voice or (least secure) by email. What in hell was I thinking when I wrote about a ``sufficiently paranoid signature''? I meant ``sufficiently paranoid person'', of course! I had intended to be funny, and funny I was, even beyond my wildest dreams! >Have fun. That still holds, especially after reading this particularly delightful typo. Have fun. -- Stephan sig closed for inventory. Please leave your pickaxe outside. PGP 2.0 public key available on request. Note the expiration date. =-=-=-=-=-= Newsgroups: alt.security.pgp From: whitaker@eternity.demon.co.uk (Russell Earl Whitaker) Subject: Re: PGP 2.0 sites list Date: Mon, 23 Nov 1992 21:00:16 +0000 Also add to your list: /pub/ibmpc/pgp/pgp20.zip at gate.demon.co.uk -- Russell Earl Whitaker whitaker@eternity.demon.co.uk Communications Editor 71750.2413@compuserve.com EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER Board member, Extropy Institute (ExI) ================ PGP 2.0 public key available ======================= =-=-=-=-=-= From: mathew Newsgroups: alt.security.pgp Subject: Re: MacPgp Date: Wed, 25 Nov 92 17:01:49 GMT dswartz@sw.stratus.com (Dan Swartzendruber) writes: > 1. If I try to type at anything more than a trivial speed, the keystrokes are > with the system beep. Yes. Type VERY VERY SLOWLY. > 2. It doesn't ever seem to terminate. I've left it sitting there waiting for > with no change. Yup. It took ages on my Mac too. If you're running it on a Powerbook, as I was, make sure your Powerbook doesn't go into "power save" mode, which slows the machine down to 1/8 of the normal speed. > Am I missing something? Yes. MacPGP is VERY VERY SLOW. It took it several minutes to read my keyfile from my PC at work. I can easily believe that it takes more than five minutes to generate a key. Be careful when typing your password in, too. The program only seems to be able to cope with about two keystrokes per second. mathew =-=-=-=-=-= Newsgroups: alt.security.pgp,sci.crypt From: hmiller@lucpul.it.luc.edu (Hugh Miller) Subject: PGP vs. RIPEM Date: Thu, 26 Nov 1992 05:44:45 GMT 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. Some examples of how this influences their conceptual design follow. PEM integrates much of the cryptographic information into Internet style headers; PGP uses a more compact and efficient system-independent binary packet data structure. PEM's email-plus design exposes more information for traffic analysis than does PGP's standalone design. A major point is that PEM has a quite different concept of "identity" than does pgp. A major concept in PEM is that an identity is a mailbox in the internet heirarchical form; keys are then certified (through a similar heirarchy of organizations propagating trust from on high) as being connected to this "mailbox identity". This design makes a lot of sense from the Internet sense (domain heirarchies being already integral to the Internet conceptual model). PGP follows a different drummer, with different strengths and weaknesses. The fundamental concept of identity is the keypair itself. This is sufficiently different to deserve some background. 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. 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. 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. 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. 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. 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. 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. This is a very important difference, much more than whether IDEA or DES is used for encryption (as these will change). PGP would lose a great deal if it were limited to Internet mail applications (conceptually). On the other hand, it loses some "application specific targeting" by not being limited to Internet mail. Each approach has its tradeoffs. PGP may nevertheless become more integrated with given mail software over time; it's not impossible to make it easier to use from within a given mail package, as easy as RIPEM even. Certainly, it will be much easier to migrate PGP into RIPEM's limited application scope than vice versa! Just don't ask for a "PEM compatible" form of PGP - it was designed for a different and larger scope; if you want PEM compatibility, use RIPEM or some other implementation. Implementing IDEA in RIPEM, or DES in PGP, wouldn't scratch the surface towards making them "compatible"; those are just details. The serious incompatibility is that they address different needs, and were both designed differently from the ground up so as to meet those needs. -- Zhahai Stewart - via ParaNet node 1:104/422 UUCP: !scicom!paranet!User_Name INTERNET: Zhahai.Stewart@f93.n104.z1.FIDONET.ORG ***** End Info-PGP Digest ***** From sbranch Thu Nov 26 17:38:40 1992 Return-Path: Received: by well.sf.ca.us (5.65c/SMI-4.1/well-921112-2) id AA06307; Thu, 26 Nov 1992 17:38:23 -0800 Date: Thu, 26 Nov 1992 17:38:23 -0800 From: Kim Clancy Message-Id: <199211270138.AA06307@well.sf.ca.us> To: aissecur Subject: hey Joe, just a note for you. No mail to be downloaded just a note in all this mess. Just wanted to wish you a happy holiday. Had a helluva day Wednesday, told Dick I was seriously thinking of getting another job. He let me interview GS-7 candidates all day and then when I told him who I wanted to hire he said, how can you justify hiring a 7 over the 12. I just lost it. I coulnd't take anymore. I told him he should have discussed that with me before he let me spend my entire day interviewing folks. That I have 1000 other priority deadlines to meet and I don't have time to be jerked around like this by him. He said I was over reacting and told me to go on vacation and calm down. He asked me to reconsider filling the 7 instead of the 12. I told him NO, that was my decision. He could do whatever he wanted but my decision remains the same. I guess I will know his answer when I get back. Anyway, just thought I would let ya know what was going on in case any questions came up. I'll be better when I get back from Hawaii, promise :) Kim From clancy@first.org Fri Nov 27 10:18:29 1992 Return-Path: Received: from nkosi.well.sf.ca.us by well.sf.ca.us with SMTP (5.65c/SMI-4.1/well-921112-2) id AA13213; Fri, 27 Nov 1992 10:18:14 -0800 Received: from first.org (CSRC.NCSL.NIST.GOV) by nkosi.well.sf.ca.us (5.65c/SMI-4.1/nkosi-921112-1) id AA00838; Fri, 27 Nov 1992 10:20:21 -0800 Received: by first.org (4.1/NIST) id AA19314; Fri, 27 Nov 92 13:18:37 EST Date: Fri, 27 Nov 92 13:18:37 EST From: Kim Clancy Organization: FIRST, The Forum of Incident Response & Security Teams Posted-Date: Fri, 27 Nov 92 13:18:37 EST Message-Id: <9211271818.AA19314@first.org> To: aissecur@well.sf.ca.us Subject: more >From virus-l@lehigh.edu Wed Nov 25 12:23:00 1992 Return-Path: Received: from csmes.ncsl.nist.gov by first.org (4.1/NIST) id AA09676; Wed, 25 Nov 92 12:19:19 EST Posted-Date: Wed, 25 Nov 1992 11:44:10 -0500 Received-Date: Wed, 25 Nov 92 12:19:19 EST Errors-To: krvw@cert.org Received: from Fidoii.CC.Lehigh.EDU by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA18582; Wed, 25 Nov 92 12:13:56 EST Received: from (localhost) by Fidoii.CC.Lehigh.EDU with SMTP id AA14638 (5.65c/IDA-1.4.4); Wed, 25 Nov 1992 11:44:10 -0500 Date: Wed, 25 Nov 1992 11:44:10 -0500 Message-Id: <9211251551.AA29838@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 #188 Status: R VIRUS-L Digest Wednesday, 25 Nov 1992 Volume 5 : Issue 188 Today's Topics: Click, Click, Click when I typed help format (PC) Re: HELP! (RE: IBM PASSWORD) (PC) Re: KEY Press virus & McAfee v97 (PC) Re: SCAN 95b doesn't find MtE in EXE files (PC) Re: SCAN 95b doesn't find MtE in EXE files (PC) Re: F-PROT question (PC) DOS virus in C-TOS Partion? (PC) WARNING: Clean V97 and Freddy (PC) Re: SCAN 95b doesn't find MtE in EXE files (PC) Re: VSUM Listing (PC) Re: SCAN 97 not working on OS/2 (OS/2) Re: Things that keep me awake at night Re: Being forthcoming... Re: $100 virus handbook Re: Things that keep me awake at night Re: Things that keep me awake at night New files on risc (PC) Newer! files on risc (PC) CHRISTMA Data (CVP) MtE detection tests (part 4/5) (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: Thu, 19 Nov 92 23:17:45 +0000 >From: danielh@hadar.fai.com (Danial Ho) Subject: Click, Click, Click when I typed help format (PC) I experienced some weird behavior on my PC. When I typed "help format" or "format /?" on DOS 5.0, the screen will display CLICK: CLICK: CLICK: ------------------------------ Date: Thu, 19 Nov 92 19:16:08 -0500 >From: Anthony Naggs Subject: Re: HELP! (RE: IBM PASSWORD) (PC) A couple of weeks back Brian W. Gamble suggested providing custom BIOS chips for PCs: > You do, however, point up a bigger problem - the sad lack of options > when one wants a BIOS version to match a particular set of > circumstances. I suspect that there is a market for this - picure > walking into a better grade of computer store. A PC in the order area > presents a menu driven system. You select your present (or just > ordered) motherboard, then choose from a list of BIOS options like: > > [...] Sounds pretty good, lets look a little further... > Seclect what you need, then the system programs a set of chips (a > matter of minutes from direct observation.) Given the amount of effort > devoted to virus creation, the amount of work required to do this > seems small. Do I oversimplify? I think so. > The equipment required to program the chips is not that expensive, nor > is it difficult to use. You would require (semi-)custom equipment to track which BIOSes were programmed, and to store the masters on hard disk, (master chips could be borrowed or stolen to produce illegal copies). > The biggest problem I see is the database > required to match the BIOS type and chip type to the motherboard in > question. This is probably the simplist part of the scheme, although collecting all the data may have minor problems. > Perhaps those with more direct knowledge would comment? Okay, :-), here goes: Most small PC manufacturers buy standard ROMs direct from AMI or Phoenix, etc.. larger manufacturers buy in the code or produce their own, again these are produced on ROMs. Now we need to look at the cost of this form of BIOS chip. As I am not entirely upto date on costs I'll use illustrative numbers for comparison only, don't quote these as 'true costs', thank-you. ROM form of BIOS costs: $10 000 engineering costs for ROM mask (1 off per BIOS version) $ 5 000 for a batch of 1000 ROMs, ie $5 each $ 1 000 for automatic assembly of 1000 ROMs into circuit boards, ie $1 each If a total of 1000 ROMs are used the cost each is $10+$5+$1 => $16 If a total of 10000 ROMs are used the cost each is $1+$5+$1 => $7 Your proposed custom BIOS system: $ 3 000 for EPROM programming equipment, with audit of use and internal storage of masters, (1 per store) $ 7 000 for static safe work benches, etc, for programming and installing BIOS chips with no risk of electro-static damage to components. (1/ store) $10 000 for a batch of 1000 one-time-programmable (E)PROMs, ie $10 each $ 10 cost for employee to spend 15 minutes to help each customer select requirements, program the chips, install in the motherboard, close PC's case, (each) If a total of 1000 ROMs are used the cost each is $3+$7+$10+$10 => $30 If a total of 10000 ROMs are used the cost each is $1+$10+$10 => $21 These costs look reasonable, but there are other costs. Firstly the store would loose sales of other display products by giving space to this service, which must be recouped. Also the store will want to market this as a 'premium' service, justifying a large mark-up on the costs. Not forgetting the increased costs in administering the royalties, and wasteage of damaged parts. And even the cost of the technician isn't straight forward, specialist work is always charged at a very high rate by companies - even when the 'specialist' is on minimum wages. Altogether you are likely to be charged over $150 for the service, and breaking the system assembly into factory and shop stages is likely reduce system reliability. Here's a variation: Install an extra bank of switches on new system boards, more technical customers could then remove the PC case and alter the switches to select the BIOS features desired. A standard BIOS can then examine the switches and enable special features or disable standard ones accordingly. This has few of the problems of your suggestion, although it is a little inconvenient. However, as only a small proportion of users will want to vary from the default features the supplier is likely to charge only an amount similar to requesting an extra i/o card. Mail order suppliers, both big brands like DELL and the stores advertising in Computer Shopper, generally assemble PCs to order and it would be trivial for them to set the BIOS configuration for you. I hope the above is constructive and helpful to you. Anthony Naggs Software/Electronics Engineer P O Box 1080, Peacehaven (and virus researcher) East Sussex BN10 8PZ Phone: +44 273 589701 Great Britain Email: (c/o Univ of Brighton) amn@vms.brighton.ac.uk or xa329@city.ac.uk ------------------------------ Date: Fri, 20 Nov 92 03:49:33 +0000 >From: mcafee@netcom.com (McAfee Associates) Subject: Re: KEY Press virus & McAfee v97 (PC) Hello Vesselin, bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >mcafee@netcom.com (McAfee Associates) writes: >> I understand that, believe me. We will fix any such problems reported >> to us. > >Will you? Any such problems? Let's hope... Because, if memory serves Yes, generally speaking we do fix any reported problems. There are obviously going to be certain times that we don't, for example, when a user thinks one of the options should be a default, or one of the defaults should be an option. Of course, that example is not so much a bug report as an enhancement request. This is not to say that we don't listen to requests for enhancements from users. Case in point: A network administrator had all sorts of drive assignments across his LAN where every other user had different drive letters for their local hard disks (if any were present). He was having difficulty setting up login scripts to test for the presence of each drive and then run SCAN against them, so we added an option to interrogate the system and find out which drivers were there, and scan them. Or the /X switch, which told SCAN to/not to (was changed several times) look for "extinct" viruses. Not very popular and was removed. Or the guy up in Seattle who wanted a 1" margin on the .DOC files so he could punch holes in them and place them in a binder. But I digress, getting back to your message >correctly, I am reporting such problems to you since about a year... >Such problems include: > >1) Viruses mentioned in VIRLIST.TXT but never reported by SCAN. > >2) Viruses reported by SCAN but never mentioned in VIRLIST.TXT. > >3) Viruses mentioned under one name in VIRLIST.TXT, but reported under >a slightly different name by SCAN. > >4) Viruses described with wrong properties in VIRLIST.TXT. Yes. Those were all present in older versions of the VIRLIST.TXT. As the number of viruses (and variants) increased, it became more difficult to maintain and inaccuracies would creep in. However, with V97 of the VIRLIST.TXT, we did a major update of the file (and continued it with V99) which brings its level of accuracy back up to par. In the meantime, we're currently developing some new tools to keep the VIRLIST.TXT file up-to-date. If you do come across any mistakes in it, please send email to my "aryeh@mcafee.COM" account and I will forward it to the appropriate parties here so that it can be fixed for the next release. >5) Several (often - completely different) viruses reported with one >and the same name. This is the most dangerous problem, since it causes >misidentification. As a reply of one of my reports about these, I got >a very angry reply from John McAfee himself. The reply was posted from >your account, so you should know about it. It claimed that the viruses >mentioned by me are actually closely related. Those viruses were >Number of the Beast, Compiler.1, and Darth Vader. Anybody who has >bothered to disassemble them knows that they are completely >different... BTW, SCAN 97 still reports all the three of them as "512 >[512]"... :-( We'll get working on that shortly, Vesselin. Regards, Aryeh Goretsky Technical Support PS: Have you had a chance to look at SCAN V99 yet? It should be available from mcafee.com and the simtel20 mirror sites by now. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 ------------------------------ Date: Mon, 16 Nov 92 19:04: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 Otto, in your message dated 11-11-1992 you wrote: OS> 2. infer from that algorithm the set of all decryptors that can possibly OS> be produced from the MtE (of course not as a huge list of detailed OS> code sections, but rather as a comparably moderate list of possible OS> features, or patterns), and prove that the set is indeed produced by OS> the algorithm, In fact my program searches for "clues", but you cannot be absolutely sure. There are a lot of programs that have encrypted data and codes inside, and these programs use routine for unencrypting data that *MAY* be very close to an Mte unencrypting routine. OS> 3. design an algorithm to detect all of these decryptors, reliably, and OS> prove that it indeed does so. The trouble is represented by the word ALL. Of course you can't spend 10 minutes for each file to be examined, or you'll never get a virus simply because....you'll never use your PC. :-) The number of viruses is increasing and scanners will become bigger and slower, so you cannot spend all your time to scan your disks. If you try other ways to detect Mte (my program does) then you must put some restriction or you'll get a lot of false alarms. OS> results than it has starting states. Outline proof 2: The length of the OS> produced code sections is limited by the size of the largest disk avail- OS> able, hence finite, hence the set of all possible code sections is the OS> power set of a finite set, which is still finite -- and the MtE will only OS> produce a small :-) subset of that power set.) I guess your idea of "small" is a bit different from mine, isn't it ? :-) _ Ciao. /\\ _\\ \/teve. - --- Mercurio 1.10 * Origin: Move fast in the tunnels of the underground. (9:391/108) ------------------------------ Date: 20 Nov 92 08:22:40 +0000 >From: duck@nuustak.csir.co.za (Paul Ducklin) Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC) Thus spake medici@dorm.rutgers.edu (Mark Medici): [stuff about COM2EXE "encryption" of viruses deleted] >Of course, if a person didn't take the time to check the .COM for >virus before converting to .EXE (or compressing with PKLITE/LZE/etc), >s/he is asking for trouble anyway. But that doesn't exclude a baddy >from doing this on purpose to make the virus harder to detect. Sure. But it's unreasonable to expect anti-virus software authors to cater for grillions of different self-compression etc. utilities because of the vague risk that a "baddy" might use one of these grillions of "well-known" utilities to produce a harder-to-detect vector for a well-known virus. Surely, in any case, the "baddy" who wishes to o something along these lines will take the trouble to produce the grillion-and-oneth self-compressor... - -- - --..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..--..-- Paul Ducklin duck@nuustak.csir.co.za CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa ------------------------------ Date: Fri, 20 Nov 92 08:42:33 -0600 >From: Jim Erickson Subject: Re: F-PROT question (PC) PNYAPTN@pacevm.bitnet (tuan) writes: >Virus-lers, > > Can any tell me why "Blem wit" is the program name when I load ^^^^^^^^ proBLEM WITh ^^^ ^ Not enough characters in the field to contain the whole phrase. - ---JRE--- ------------------------------ Date: Fri, 20 Nov 92 11:04:00 -0600 >From: "BARRY P." Subject: DOS virus in C-TOS Partion? (PC) At work we have several Burroughs machines that have DOS partitions and we access them with Virtual PC. If we contract a DOS virus on the Burroughs' DOS partition, will it also attack the C-TOS partition and if so will it do the same thing as it would on a DOS machine. I realize this depends a lot on the virus itself. Does anyone have any information that would help me? ------------------------------ Date: Fri, 20 Nov 92 15:23:21 -0500 >From: sapao@dcc.ufmg.br Subject: WARNING: Clean V97 and Freddy (PC) Clean v97 does not work disinfecting the Freddy virus. Scan v97 reports: The Jeru [Jeru] virus was found... Using clean to remove the virus will corrupt the files, which will hang the computer when run. All files tested hanged the computer, even those which size was exactly the same as before the infection. Clean reported multiple infections in COM files, and seems to wipe out the begining of the program until it removes the virus signature. The command line used was: CLEAN [JERU] C: The test results are in the table below. Test Results: Clean v97 with Freddy. : SIZE (BYTES) : FILES :----------------------------------------------: NUMBER OF : BEFORE : INFECTED : AFTER : VIRUSES FOUND : INFECTION : : DISINFECTION : IN FILE - ------------:---------------:-------------:----------------:------------- COMMAND.COM : 47845 : 47922 : 914 : 26 : : : : FORMAT.COM : 32911 : 34781 : 429 : 19 : : : : MORE.COM : 2618 : 4488 : 872 : 2 : : : : CLEAN.EXE : 104976 : 106846 : 104976 : 1 : : : : F-PROT.EXE : ? : 112574 : 110704 : 1 : : : : MI.COM : 8640 : 10510 : 1470 : 5 : : : : TBSCAN.EXE : 23392 : 25262 : 23392 : 1 : : : : FIND.EXE : 6770 : 8654 : 6784 : 1 DOS VERSION : 5.0 PS: SCAN V99 REPORTED THE SAME AS V97. LUCAS DE CARVALHO FERREIRA - COMPUTER SCIENCE STUDENT - UFMG - BRAZIL INTERNET: SAPAO@DCC.UFMG.BR BITNET: GFAFA002@BRUFMG.BITNET ------------------------------ Date: 20 Nov 92 22:34:38 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC) mcafee@netcom.com (McAfee Associates) writes: > Are you sure? I can see two opposing schools of thought forming here: > One of "all or nothing" detection (the binary operation school of > thought), and one of "percentages" of detecting (the analog school of > thought)? Without getting too far off track, here, I believe that I would like to ask all those who belong to the second school of thought: Will you really want to reply for virus protection on a program that misses one infected file in every N? Especially if you know that there are programs that -don't- miss any files infected by this virus? If yes, then for what values of N? One infection missed in every 50? In every 100? In every 1,000? In every 10,000? > there will be more "percentage" reports in the future, especially as > more complex forms of viral code emerge. That's what I am also afraid of; and that's why I am pushing for 100% reliable detection... > The article (I wish I knew which one) could have have said that. It I think I could find you a copy of the article, if you are interested... > >of the competitive scanners were used in those tests and that he was > >quoted saying that he wants his competitors to show worse results in > >such tests. To do otherwise might be worthless from the economical > I think its fairly easy to guess that John McAfee would like his programs > to do better then anyone else's in a test. I'm sure that is hardly > unique, though. Don't change the wording. The article quoted him saying that he wants his competitors to show worse results, not him to show better results... This is not quite equivalent. > If possible, would you mind sending me a copy of any such reports? (Only > on McAfee Associates software, that is). Thank you. I am doing so since some time. I am sending a copy of the reports to Igor Grebert, as you have advised me. > PS: SCAN V99 should be available about the time you read this. I'd > be very interested in hearing how it does--the MtE-based virus > detector was rewritten. AG Got it and did the tests. Will post the results, but in a separate message; the subject line for this one is not appropriate... Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 20 Nov 92 22:44:43 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: Re: VSUM Listing (PC) gerald@vmars.tuwien.ac.at (Gerald Pfeifer (Prak Gusti)) writes: > Yes, it runs an 8088 to 80486, and on Hercules as well as on VGA.... > The VSUM-package contains everything you need except DOS.... One important feature it lacks is to print the description of the virus in an ASCII file. You can print it to the printer, but not in a file. (Of course, this can be hacked out, but I would prefer to see the feature included in a more natural way.) Furthermore, the hypertext engine is in fact the one developed by Flambeux Software (sp?) and distributed with their Tech Help!. This allows to have just one hypertext engine resident and use both VSUM and the Tech Help! database. > BUT: Some experts (Bontchev, Frisk...) in this group do *not* recommend VSUM. Why, it is still the most complete collection of descriptions of MS-DOS viruses. I am complaining mainly because most of those descriptions contain technical incorrectnesses... Often - significant ones... :-( > A while ago I heard that the VTC Hamburg (where Bontchev works) is going > to release a dBase version of there virus catalog. I have not seen it > yet, but if anyone in this group knows, please let us know..... That's true, we are working on the subject, but don't expect the product to be ready soon. At first it will be probably just a hypertext browser of the Computer Virus Catalog, which itself will be kept in dBase format... But, as I said, it will not be ready soon. Regards, Vesselin - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ------------------------------ Date: 20 Nov 92 14:59:35 +0000 >From: co@chrom1.mednet.gu.se (Christer Olsson) Subject: Re: SCAN 97 not working on OS/2 (OS/2) jhk@washington.ssds.COM (jhk) writes: |> Ref Scanv97 not working with OS2 .... McAfee released (BETA i think) a |> copy of SCANOS2 ... I dloaded it off the HomeBase BBS last week. I've also tested the OS/2-version, but it hangs on my second HPFS-drive. It's still a Beta-verision... ------------------------------ Date: 19 Nov 92 22:48:55 +0000 >From: tck@fold.ucsd.edu (Kevin Marcus) Subject: Re: Things that keep me awake at night ygoland@edison.SEAS.UCLA.EDU (The Jester) writes: >Silence. That is what I hear on this net.group. I hear silence. There >is some discussion about a particular program's ability to detect a >virus and then there is the reason I still read this group, new >product announcements. But the one thing I'v never seen is a >discussion of the mechanics of fighting viruses. Is the viral world >satisfied with it's basic tools, scanner, activity/change monitor, and >heuristic analyizers? Is that the end? Are all of the people in the >community doing nothing more than comming up with new scan codes for >whatever virus has shown up this week, trying to understand the ugly >inards of some os so they can tweak their monitors a little better, >and trying to see yet another combination of code that only a virus >would use? Why is there no real discussion on techniques and ideas? Is >this part of the conspiracy of silence that infects the viral >community? I disagree. For example, I just mentioned methods of fighting MtE based viruses. However, this group is more than likely read (and maybe participated in ) by virus authors. Telling them how you can find or evade their creations will only help them make it harder for AV researchers. More intense discussion is often left to email. ------------------------------ Date: Fri, 20 Nov 92 04:00:16 +0000 >From: mcafee@netcom.com (McAfee Associates) Subject: Re: Being forthcoming... Hello Tarkan, tyetiser@umbc5.umbc.edu (Mr. Tarkan Yetiser) writes: [...message from me about being forthright with users of McAfee software with respect to bugs and bug-fixes deleted for brevity...] > In keeping up with this tradition of open communications with your >users, would you please share with the readers of this newsgroup the >press release from McAfee Assoc., dated May 11, '92 and titled "Dark >Avenger Mutation Engine No Threat to Protected PCs", with the contact >name Mr. McKiernan? Out of curiosity, is William McKiernan a McAfee >agent or employee? No, I won't. However, if you'd like, I'm sure that you can contact William (Bill) McKiernan for a copy. Bill can be reached at telephone 1-(408) 988-3609 or you can send a fax to him at 1-(408) 970-9727. He's not on the Internet, but I do believe he has a CompuServe account that you should be able to reach via the Internet. I'll see if I can find a user I.D. for him. Bill currently serves as President and Chief Operating Officer of McAfee Associates, Inc. However, at that time, he would have been acting in capacity as Vice-President of Marketing. I'm sure Bill would be happy to answer any questions about press releases. Regards, Aryeh Goretsky 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 ------------------------------ Date: Fri, 20 Nov 92 03:23:16 -0800 >From: Richard W. Lefkon Subject: Re: $100 virus handbook There isn't a "$100 Virus Handbook" I know of per se, but 3 come close: 1 - Computer Virus Handbook, Lo about $184 from Elsevier, 256 Banbury Road, Oxford OX2 7DH England (L92) (375pp) 2 - Virus & Security Conference Proceedings, $100 from DPMA Financial Ind. Chapter, Box 894, NY NY 01268 ($100, 870pp) (specify '91 or 92 - or '93 if you can wait 'til March) 3 - Computer Security Handbook (price? 500pp) from CSI, 500 Howard Street, SF 94105 - -dick (p.s. this writer edits #2) ------------------------------ Date: Fri, 20 Nov 92 15:35:35 +0000 >From: gary@sci34hub.sci.com (Gary Heston) Subject: Re: Things that keep me awake at night ygoland@edison.SEAS.UCLA.EDU (The Jester) writes: >Silence. That is what I hear on this net.group. I hear silence. There >is some discussion about a particular program's ability to detect a >virus and then there is the reason I still read this group, new >product announcements. But the one thing I'v never seen is a >discussion of the mechanics of fighting viruses. If by "mechanics" you mean policies and proceedures oriented towards prevention, early detection, and containment, then I suggest you have your newsfeed checked. I see a fair amount of this type of discussion going on. (I also see 15-30 articles per day, which I don't consider to be "silence".) >Is the viral world >satisfied with it's basic tools, scanner, activity/change monitor, and >heuristic analyizers? Is that the end? Are all of the people in the >community doing nothing more than comming up with new scan codes for >whatever virus has shown up this week, trying to understand the ugly >inards of some os so they can tweak their monitors a little better, >and trying to see yet another combination of code that only a virus >would use? Why is there no real discussion on techniques and ideas? Is >this part of the conspiracy of silence that infects the viral >community? A basic tenent of this type of thing is to not let the "bad guys" know just how their viruses are being detected. Once the detection method is known, then a directed attack (as the Monkey virus reports recently seem to qualify as) against the antiviri software becomes *much* easier. I, for one, don't care to see things made easier for Dark Avenger and his cohorts. They are a festering sore on the computing community; I can think of several suitable punishments (strand on a desert island with no computers, network connections, pizza, or Jolt, for example) if they ever are tracked down. Certainly, the businesses who have suffered data loss and disruption of work would have civil actions to pursue. I'm not sure why you see a conspiracy of silence. I don't. I see a great deal of intense programming effort being expended to counteract the malicious acts of a few. The people expending the effort are wisely not posting the details of what they do, which slows the development of viruses. (It also protects them from competitors, since most of these people can't work for free.) The level of activity I see is satisfactory to me. I don't know if there could be much more discussion of the type you want to see without aiding the virus writers. - -- Gary Heston SCI Systems, Inc. gary@sci34hub.sci.com site admin The Chairman of the Board and the CFO speak for SCI. I'm neither. "Data sheet: HSN-3000 Nuclear Event Detector. The [NED] senses the gamma radiation pulse [from a] nuclear weapon." As if we wouldn't notice... ------------------------------ Date: 20 Nov 92 21:39:38 +0000 >From: valdis@black-ice.cc.vt.edu (Valdis Kletnieks) Subject: Re: Things that keep me awake at night ygoland@edison.SEAS.UCLA.EDU (The Jester) writes: >product announcements. But the one thing I'v never seen is a >discussion of the mechanics of fighting viruses. Is the viral world >satisfied with it's basic tools, scanner, activity/change monitor, and >heuristic analyizers? Is that the end? Are all of the people in the >community doing nothing more than comming up with new scan codes for >whatever virus has shown up this week, trying to understand the ugly >inards of some os so they can tweak their monitors a little better, >and trying to see yet another combination of code that only a virus >would use? Why is there no real discussion on techniques and ideas? Is >this part of the conspiracy of silence that infects the viral >community? A few points to ponder: (a) I remember a *lengthy* discussion within the last year concerning the Turing halting problem and whether it was theoretically possible to detect all virii on a finite-sized machine. (b) There's a lot of different virus critters out there, and tweaking scan codes needs to be done. (c) I think the "techniques and ideas" is for the most part fairly well understood by most of the "power players" in the field. There *are* after all only a finite number of effective ways to write a virus - boot sector, .EXE infiltrator, etc. (d) A certain amount of discretion *does* need to be used when dealing with security-related issues. I've found security problems in a number of different vendor's products, and there is *always* the problem of trying to decide how to tell "enough" of the hole so that people are convinced that there is a problem, but *not* so much that every hacker in the world can exploit it before there is a patch available. Do you *want* somebody to post "Hey World - if you put the hex string x'AEDF12E7' in a virus, no known virus checker will see it?" (e) You say you don't see "a discussion of the mechanics of fighting viruses", but then say there's too much discussion of scan codes and all. Isn't this in fact 'the mechanics' of it? I'm not sure what exactly you DO want to see more of in this newsgroup. Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------ Date: Thu, 19 Nov 92 21:11:59 -0500 >From: James Ford Subject: New files on risc (PC) The following files have been placed on risc.ua.edu (130.160.4.7) for anonymous FTP in the directory /pub/ibm-antivirus: scanv97b.zip - McAfee's Scan v97b clean97.zip - McAfee's Clean v97 wscan97b.zip - McAfee's Scan v97b for Windows vshld97.zip - McAfee's VirusShield v97 netsc97b.zip - McAfee's NetScan v97b nshld103.zip - McAfee's NetShield NLM for Novell v3.11 Nets mtetests.zip - Vesselin (VTC-Hamburg) Mte Test results fp-206.zip - Frisk's F-Prot v2.06 Please note that new files which appear in Virus-L are usually placed online on risc.ua.edu within 48 hours while announcments via mibsrv-l@ua1vm.ua.edu may take later. - ---------- The person who snores loudest will fall asleep first. - ---------- James Ford - Consultant II, Seebeck Computer Center The University of Alabama (in Tuscaloosa, Alabama) jford@ua1vm.ua.edu, jford@seebeck.ua.edu Work (205)348-3968 fax (205)348-3993 ------------------------------ Date: Thu, 19 Nov 92 22:09:05 -0500 >From: James Ford Subject: Newer! files on risc (PC) Three files have already been replaced on risc.ua.edu (130.160.4.7). They are: scanv99.zip - McAfee's Scan v99 netsc99b.zip - McAfee's NetScan v99b fp-206a.zip - Frisk's F-Protect v2.06a - ---------- The graveyards are full of indispensable men. - ---------- James Ford - Consultant II, Seebeck Computer Center The University of Alabama (in Tuscaloosa, Alabama) jford@ua1vm.ua.edu, jford@seebeck.ua.edu Work (205)348-3968 fax (205)348-3993 ------------------------------ Date: Fri, 20 Nov 92 15:13:03 -0800 >From: rslade@sfu.ca Subject: CHRISTMA Data (CVP) Having had now three responses to the first two postings on the CHRISTMA worm (and having still four more "in the can" ready to go), I feel some need to respond. Not that I think I am being flamed and need to defend myself: quite the contrary, i am extremely thankful for the additional information and correction. I do, however, feel that I should make some attempt to regather the tattered shreds of my credibility before I lose it entirely. When I started into the "history" section of the CVP series, I made a very bad mistake in failing to thoroughly research my original source materials for the Jerusalem virus. having learned from that mistake, I hope my subsequent columns have demonstrated better research. CHRISTMA, however, seems to have had significant errors in the reporting, which was extensive. (My "research" file on CHRISTMA alone runs to slightly under 200K.) Bridget, for example, states that CHRISTMA did not clean itself up. She must know, since she had to clean up the remaining files. However, numerous reports state that once CHRISTMA had mailed itself off, the "original" message deleted itself. David Chess is concerned that I am spreading an urban with in stating that VNET had to be shut down. I'd be concerned, too, and I apologize if I am spreading falsehoods that way. I must admit, that, aside from one newswire report, which I wouldn't trust by itself, my "source material" for this is only one message, albeit an otherwise accurate and authoritative message which, despite broad circulation, was never (to my knowledge) publicly refuted. I suppose that this is part of the reason that I write the column. I hope that "neophytes" derive some information and background from it that is helpful. However, I hope that I am also choosing "important" events in "viral computing", and I hope that those with direct experience of some of these issues will continue to correct errors that I may let slip by. Anyhow, enough whining and self-justification. On with the regularly scheduled column. HISVIRJ.CVP 921022 CHRISTMA Data Once again, the CHRISTMA EXEC demonstrates a virus (or, more exactly, a worm) in an area that is generally thought to belong to data. Although IBM mainframe systems can use mail to transfer files (mail is, in fact, simply a specialized case of file transfer), the CHRISTMA message was contained in text. REXX source code, to be exact. It is often said, when answering the frequent question about whether a virus can be transmitted via a data file or a message, that the line between data and programming is very blurred. This is quite true. In fact the MAKEBOO program, a utility for converting binary files into printable characters, suitable for transmitting across email systems, itself contains only printable characters. The MAKEBOO program, then, can be sent, as a message, over normal email systems. (Those wishing a copy of MAKEBOO, please get it from SIMTEL or some other site. I *cannot* function as a fileserver.) The CHRISTMA EXEC, however, was not a program in this sense. An EXEC is a source code program, which is then run by an interpreter. REXX is, then, an interpreted, rather than a compiled language, much the same as most BASIC interpreters. No object code is ever produced in this kind of situation. In that case, what is the source code? A program to be run, or a data file to be edited? The answer, of course, is both. Interpreters are making a resurgence. While interpreted programs are much slower than compiled ones, modern computers are fast enough to deal with the speed problem. In addition, interpreted languages allow the programs to be run on multiple platforms without object code compatibility problems. There is no need to adjust, or even recompile, the code. Simply run what you are given. REXX interpreters are available on a wide variety of platforms. Many other similar languages are available. Indeed, application programs are tending to become such interpreters. "Programs" are being written in 1-2-3 and Word Perfect. Terminal emulators, as well, have "scripting" languages that are being used to automate any function that users might have the slightest difficulty with. "Groupware" is this year's buzz word. Groupware will rely heavily on the configuring, automating and presentation of functions through exactly these kind of systems. "Open systems" and cross platform compatibility, both desperately desired by users and corporations, will also present opportunities to the authors of viral programs. copyright Robert M. Slade, 1992 HISVIRJ.CVP 921022 ============== Vancouver p1@arkham.wimsey.bc.ca | You realize, of Institute for Robert_Slade@sfu.ca | course, that these Research into rslade@cue.bc.ca | new facts do not User p1@CyberStore.ca | coincide with my Security Canada V7K 2G6 | preconceived ideas ------------------------------ Date: 02 Nov 92 18:12:38 +0000 >From: bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) Subject: MtE detection tests (part 4/5) (PC) Hello, everybody! Here is the long awaited report about the MtE detection tests that we performed at VTC-Hamburg. It is rather longish, so maybe Ken should consider splitting it into parts. Normally, I should have put it for anonymous ftp, instead of publishing it here, but the preliminary results of the tests raised enough interest and discussions, so I decided to publish it in a whole in this newsgroup. Nevertheless, it - - -is- available for anonymous ftp as ftp.informatik.uni-hamburg.de:pub/virus/texts/tests/mtetests.zip [Moderator's note: The complete text of Vesselin's MtE tests are also available from: cert.org:pub/virus-l/docs/mtetests.zip As I had previously indicated, I have broken Vesselin's tests down into five parts and will post each seperately.] Enjoy. Comments, questions, and suggestions are welcome. Regards, Vesselin - - -- Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg Tel.:+49-40-54715-224, Fax: +49-40-54715-226 Fachbereich Informatik - AGN < PGP 2.0 public key available on request. > Vogt-Koelln-Strasse 30, rm. 107 C e-mail: bontchev@fbihh.informatik.uni-hamburg.de D-2000 Hamburg 54, Germany ===== [part 4/5] 4. The results. For each scanner we give the number of samples that it has detected, the total number of samples, and the number of missed samples. The notation used is "Detected/Total/Missed". Obviously, Total - Detected = Missed. When Detected == Total, we also give the results of the additional tests, using the same notation, on the next line, but only if they show that the scanner does NOT detect that particular virus reliably. Codename: ANTIVIR Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 0 2000 2000 NO CryptLab 2000 2000 0 Yes Dedicated 2000 2000 0 Yes Fear 2000 2000 0 Yes Groove/EXE 0 2000 2000 NO Groove/COM 2000 2000 0 Yes Pogue 2000 2000 0 Yes Questo 1994 1994 0 Yes Comments: 1) This is German-only product. As far as I know, no English version is available. 2) Obviously, the algorithm for MtE detection contains a bug, which prevents it from detecting the MtE in EXE files. Otherwise the algorithm seems reliable. Let's hope that the bug will be corrected soon. Codename: AVP Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 1862 2000 138 NO CryptLab 1999 2000 1 NO Dedicated 2000 2000 0 Dedicated 107 108 1 NO Fear 2000 2000 0 Yes Groove/EXE 1857 2000 143 NO Groove/COM 1878 2000 122 NO Pogue 2000 2000 0 Yes Questo 1853 1994 141 NO Comments: 1) When run in interactive mode, the program just aborts with the message "No memory". The amount of free conventional memory during the tests was 505 Kb. 2) When run in command-line mode, the program refused to create a log file, regardless that it was instructed to do so. Codename: CATCHMTE Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 2000 2000 0 Yes CryptLab 2000 2000 0 Yes Dedicated 2000 2000 0 Yes Fear 2000 2000 0 Yes Groove/EXE 2000 2000 0 Yes Groove/COM 2000 2000 0 Yes Pogue 2000 2000 0 Yes Questo 1994 1994 0 Yes Codename: CPAV Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 1724 2000 276 NO CryptLab 1999 2000 1 NO Dedicated 2000 2000 0 Dedicated 101 108 7 NO Fear 2000 2000 0 Yes Groove/EXE 1998 2000 2 NO Groove/COM 2000 2000 0 Yes Pogue 2000 2000 0 Pogue 86 102 16 NO Questo 1992 1994 2 NO Comments: 1) During the additional tests, one file caused CPAV to hang while testing it. A file should be either detected as infected, or not, but by no means should the program crash when scanning it. 2) CPAV insisted to broadcast warnings about the found infections on the network, which was particularly boring. It's an useful feature, but there should be a way to turn it off. 3) The tests of this scanner were done by Mattias Jaenichen. Codename: F-PROT Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 2000 2000 0 Yes CryptLab 2000 2000 0 Yes Dedicated 2000 2000 0 Yes Fear 2000 2000 0 Yes Groove/EXE 2000 2000 0 Yes Groove/COM 2000 2000 0 Yes Pogue 2000 2000 0 Yes Questo 1994 1994 0 Yes Codename: FINDVIRU Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 2000 2000 0 Yes CryptLab 2000 2000 0 Yes Dedicated 2000 2000 0 Yes Fear 2000 2000 0 Yes Groove/EXE 2000 2000 0 Yes Groove/COM 2000 2000 0 Yes Pogue 2000 2000 0 Yes Questo 1994 1994 0 Yes Codename: GOBBLER Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 2000 2000 0 Yes CryptLab 1881 2000 119 NO Dedicated 2000 2000 0 Fear 2000 2000 0 Yes Groove/EXE 2000 2000 0 Yes Groove/COM 2000 2000 0 Yes Pogue 2000 2000 0 Yes Questo 1994 1994 0 Yes Comments: 1) The program is horribly buggy. It crashes when the total environament is more than 256 bytes, there are missing virus descriptions in the help, parts of the user interface are not designed well enough, and many other things. 2) The algorithm for MtE detection, however, seems to be excellent, except for the CryptLab virus, which the author of the program seems not to have. 3) This was the only program that properly identified each one of the samples. The other scanners just said "MtE virus" or something similar. This program even used the standard CARO notation! (E.g., "MtE_0_90.CoffeeShop".) Codename: HTSCAN Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 1863 2000 137 NO CryptLab 1880 2000 120 NO Dedicated 1873 2000 127 NO Fear 1879 2000 121 NO Groove/EXE 1857 2000 143 NO Groove/COM 1878 2000 122 NO Pogue 1894 2000 106 NO Questo 1853 1994 141 NO Comments: 1) All missed samples are unencrypted (although not all unencrypted samples are missed). The author of the product is strongly advised to put a scan string of the body of the MtE in his dabase of scan signatures and to let the AVR module to detect only the encrypted samples of the virus. Codename: NAV Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 0 2000 2000 NO CryptLab 954 2000 1016 NO Dedicated 1085 2000 915 NO Fear 1088 2000 912 NO Groove/EXE 0 2000 2000 NO Groove/COM 990 2000 1010 NO Pogue 1025 2000 975 NO Questo 932 1994 1062 NO Comments: 1) NAV 2.1 is hopeless in detecting the MtE-based viruses. 2) When run in interactive mode, NAV stopped after a few hundred infections were found, and nicely told me to remove some of the infected files and to try again. The reason is that it tries to keep the whole report in memory - something extremely stupid. 3) When run in interactive more, I couldn't force it to create a report file. Codename: PCVP Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 0 2000 2000 NO CryptLab 1821 2000 179 NO Dedicated 1845 2000 155 NO Fear 1851 2000 149 NO Groove/EXE 0 2000 2000 NO Groove/COM 0 2000 2000 NO Pogue 1998 2000 2 NO Questo 1838 1994 162 NO Comments: 1) PCVP can scan only whole drives. In the case of LANs, it can scan only whole volumes. 2) Parts of the program were not implemented yet - it is a beta version. Codename: SCAN Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 1987 2000 13 NO CryptLab 1997 2000 3 NO Dedicated 1999 2000 1 NO Fear 1999 2000 1 NO Groove/EXE 1853 2000 147 NO Groove/COM 1993 2000 7 NO Pogue 1995 2000 5 NO Questo 1852 1994 142 NO Comments: 1) Of the 147 missed Groove/EXE samples, 142 were unencrypted and 2 were damaged. Of the 142 missed Questo samples, 141 were unencrypted. Codename: TBSCAN Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 1863 2000 137 NO CryptLab 1880 2000 120 NO Dedicated 1873 2000 127 NO Fear 1879 2000 121 NO Groove/EXE 1857 2000 143 NO Groove/COM 1878 2000 122 NO Pogue 1894 2000 106 NO Questo 1853 1994 141 NO Comments: 1) The results are the same as HTSCAN, because the same AVR module is used. 2) Most of the unencrypted samples missed by the AVR module are detected by TBSCAN's heuristics and are reported as "unknown viruses". However, 33 samples of Fear were missed even by the heuristics. 3) It is NOT possible to turn the heuristics off completely, regardless what the documentation says. The -expertlog option only suppresses the (longish) explanation of each heuristic; it doesn't prevent the heuristics from working. Therefore, it is not possible to test only the capabilities of the signature database and the AVR modules to detect viruses. I find this rather annoying. Codename: UTSCAN Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 2000 2000 0 Yes CryptLab 2000 2000 0 Yes Dedicated 2000 2000 0 Yes Groove/EXE 1857 2000 143 NO Groove/COM 1877 2000 123 NO Pogue 2000 2000 0 Yes Questo 1994 1994 0 Yes Comments: 1) UTSCAN is only the scanner part of a package, which is integrity-oriented. Nevertheless, its MtE-detection algorithm seems rather good. Let's hope that the problem with the Groove virus will be fixed soon. Codename: VBUSTER Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 0 2000 2000 NO CryptLab 1880 2000 120 NO Dedicated 2000 2000 0 Dedicated 107 108 1 NO Fear 1879 2000 121 NO Groove/EXE 1839 2000 161 NO Groove/COM 1862 2000 138 NO Pogue 1949 2000 51 NO Questo 1853 1994 141 NO Codename: VIRX Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 147 2000 1853 NO CryptLab 1997 2000 3 NO Dedicated 2000 2000 0 Yes Fear 1999 2000 1 NO Groove/EXE 0 2000 2000 NO Groove/COM 0 2000 2000 NO Pogue 1998 2000 2 NO Questo 1985 1994 9 NO Comments: 1) VIRX is yet another program that commits the stupidity to keep the whole report file in memory. Of course, after a few hundred infections the memory gets filled up. Then, the program does something even more stupid - it begins to stop after EACH new infection, to inform the user that there is no memory for the report file, and to wait for a keypress. The only reason I was able to test it at all, was that it can append the results of several scans to one and the same report file, and that 4DOS supports an advanced syntax of the FOR loop, which permitted me to traverse only the directories infected by a particular virus, one at a time. Codename: VHUNTER Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 1863 2000 137 NO CryptLab 2000 2000 0 Yes Dedicated 2000 2000 0 Yes Fear 2000 2000 0 Fear 27 28 1 NO Groove/EXE 1857 2000 143 NO Groove/COM 1878 2000 122 NO Pogue 2000 2000 0 Pogue 116 119 3 NO Questo 1853 1994 141 NO Comments: 1) The author of the program claims that it is able to detect only encrypted replicants of the MtE-based viruses. Of the unencrypted replicants, only those are detected, that represent viruses known to the author. No attempt is made to detect unencrypted unknown MtE-based viruses. The tests showed that it is indeed so - all missed samples were unencrypted (although not all unencrypted samples were missed). The author is encouraged to contact us, in order to obtain samples of the MtE-based viruses that are unknown to him. Codename: VIRSCAN Virus Name: Detected: Total: Missed: Reliable? CoffeeShop 2000 2000 0 Yes CryptLab 2000 2000 0 Yes Dedicated 2000 2000 0 Yes Fear 2000 2000 0 Yes Groove/EXE 2000 2000 0 Yes Groove/COM 2000 2000 0 Yes Pogue 2000 2000 0 Yes Questo 1994 1994 0 Yes ------------------------------ End of VIRUS-L Digest [Volume 5 Issue 188] Downloaded From P-80 International Information Systems 304-744-2253