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
[email protected]. 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
[email protected]. 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 |
[email protected]
Signed PGP v.2.0 public key certificate available by e-mail & finger(1)
-------------------------------------------------------------------------------
Newsgroups: alt.security.pgp
From:
[email protected] (Lars Vatne)
Subject: Re: How secure is "casual" or "military"?
Date: Thu, 19 Nov 92 10:16:09 GMT
In article <
[email protected]>,
[email protected] (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 :
[email protected]
=-=-=-=-=-=
From:
[email protected] (James Campbell)
Newsgroups: alt.security.pgp
Subject: Re: How secure is "casual" or "military"?
Date: 19 Nov 92 12:03:29 -0600
In article <
[email protected]>, 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;
[email protected]
---------------------------------------------------------------------------
=-=-=-=-=-=
Newsgroups: alt.security.pgp
From:
[email protected] (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
[email protected]:
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:
[email protected]
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
> (
[email protected]) or the Sysop of the BBS whose address
> is
[email protected].
-- 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 (
[email protected])
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 (
[email protected]).
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 |
[email protected]
=-=-=-=-=-=
Newsgroups: alt.security.pgp
From:
[email protected] (Christopher Browne)
Subject: Re: PGP 2.0 sites list
Date: Sun, 22 Nov 92 22:55:11 GMT
In article <
[email protected]>
[email protected] (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
[email protected] |===================================
University of Ottawa | The Personal Computer: Colt 45
Master of System Science Program | of the Information Frontier
=-=-=-=-=-=
From:
[email protected] (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 <std_disclaimer.h>
Dan S.
=-=-=-=-=-=
From:
[email protected] (Zbigniew Fiedorowicz)
Newsgroups: alt.security.pgp
Subject: Re: MacPgp
Date: 23 Nov 1992 12:00:44 -0500
[email protected] (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:
[email protected] (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:
[email protected] (Zbigniew Fiedorowicz)
Newsgroups: alt.security.pgp
Subject: Re: MacPgp
Date: 23 Nov 1992 12:09:08 -0500
Edgar Matias (
[email protected]) 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:
[email protected] (Timothy C. May)
Subject: Re: MacPgp
Date: Mon, 23 Nov 1992 07:27:01 GMT
Edgar Matias (
[email protected]) 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,
[email protected] | 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:
[email protected] (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:
[email protected] (Stephan Neuhaus (HiWi Mattern))
Subject: Re: PGP 2.0 sites list
Date: Tue, 24 Nov 1992 14:33:26 GMT
[email protected] (Christopher Browne) writes:
>In article <
[email protected]>
[email protected] (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 <
[email protected]>
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:
[email protected] (Stephan Neuhaus (HiWi Mattern))
Subject: Re: PGP 2.0 sites list
Date: Tue, 24 Nov 1992 16:05:29 GMT
[email protected] (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 <
[email protected]>
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:
[email protected] (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
[email protected]
Communications Editor
[email protected]
EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
================ PGP 2.0 public key available =======================
=-=-=-=-=-=
From: mathew <
[email protected]>
Newsgroups: alt.security.pgp
Subject: Re: MacPgp
Date: Wed, 25 Nov 92 17:01:49 GMT
[email protected] (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:
[email protected] (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:
[email protected] (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:
[email protected]
***** End Info-PGP Digest *****
From sbranch Thu Nov 26 17:32:42 1992
Return-Path: <sbranch>
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 <sbranch>
Message-Id: <
[email protected]>
To: aissecur
Subject: pgpnewsletter
>From
[email protected] Thu Nov 26 00:38:42 1992
Return-Path: <
[email protected]>
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: <
[email protected]>
Subject: Info-PGP v. 1 # 34
From:
[email protected]
Date: Thu, 26 Nov 92 2:40:39 CST
Reply-To:
[email protected]
To:
[email protected]
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
[email protected]. 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
[email protected]. 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 |
[email protected]
Signed PGP v.2.0 public key certificate available by e-mail & finger(1)
-------------------------------------------------------------------------------
Newsgroups: alt.security.pgp
From:
[email protected] (Lars Vatne)
Subject: Re: How secure is "casual" or "military"?
Date: Thu, 19 Nov 92 10:16:09 GMT
In article <
[email protected]>,
[email protected] (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 :
[email protected]
=-=-=-=-=-=
From:
[email protected] (James Campbell)
Newsgroups: alt.security.pgp
Subject: Re: How secure is "casual" or "military"?
Date: 19 Nov 92 12:03:29 -0600
In article <
[email protected]>, 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;
[email protected]
---------------------------------------------------------------------------
=-=-=-=-=-=
Newsgroups: alt.security.pgp
From:
[email protected] (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
[email protected]:
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:
[email protected]
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
> (
[email protected]) or the Sysop of the BBS whose address
> is
[email protected].
-- 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 (
[email protected])
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 (
[email protected]).
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 |
[email protected]
=-=-=-=-=-=
Newsgroups: alt.security.pgp
From:
[email protected] (Christopher Browne)
Subject: Re: PGP 2.0 sites list
Date: Sun, 22 Nov 92 22:55:11 GMT
In article <
[email protected]>
[email protected] (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
[email protected] |===================================
University of Ottawa | The Personal Computer: Colt 45
Master of System Science Program | of the Information Frontier
=-=-=-=-=-=
From:
[email protected] (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 <std_disclaimer.h>
Dan S.
=-=-=-=-=-=
From:
[email protected] (Zbigniew Fiedorowicz)
Newsgroups: alt.security.pgp
Subject: Re: MacPgp
Date: 23 Nov 1992 12:00:44 -0500
[email protected] (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:
[email protected] (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:
[email protected] (Zbigniew Fiedorowicz)
Newsgroups: alt.security.pgp
Subject: Re: MacPgp
Date: 23 Nov 1992 12:09:08 -0500
Edgar Matias (
[email protected]) 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:
[email protected] (Timothy C. May)
Subject: Re: MacPgp
Date: Mon, 23 Nov 1992 07:27:01 GMT
Edgar Matias (
[email protected]) 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,
[email protected] | 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:
[email protected] (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:
[email protected] (Stephan Neuhaus (HiWi Mattern))
Subject: Re: PGP 2.0 sites list
Date: Tue, 24 Nov 1992 14:33:26 GMT
[email protected] (Christopher Browne) writes:
>In article <
[email protected]>
[email protected] (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 <
[email protected]>
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:
[email protected] (Stephan Neuhaus (HiWi Mattern))
Subject: Re: PGP 2.0 sites list
Date: Tue, 24 Nov 1992 16:05:29 GMT
[email protected] (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 <
[email protected]>
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:
[email protected] (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
[email protected]
Communications Editor
[email protected]
EXTROPY: The Journal of Transhumanist Thought AMiX: RWHITAKER
Board member, Extropy Institute (ExI)
================ PGP 2.0 public key available =======================
=-=-=-=-=-=
From: mathew <
[email protected]>
Newsgroups: alt.security.pgp
Subject: Re: MacPgp
Date: Wed, 25 Nov 92 17:01:49 GMT
[email protected] (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:
[email protected] (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:
[email protected] (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:
[email protected]
***** End Info-PGP Digest *****
From sbranch Thu Nov 26 17:38:40 1992
Return-Path: <sbranch>
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 <sbranch>
Message-Id: <
[email protected]>
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
[email protected] Fri Nov 27 10:18:29 1992
Return-Path: <
[email protected]>
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 <
[email protected]>
Organization: FIRST, The Forum of Incident Response & Security Teams
Posted-Date: Fri, 27 Nov 92 13:18:37 EST
Message-Id: <
[email protected]>
To:
[email protected]
Subject: more
>From
[email protected] Wed Nov 25 12:23:00 1992
Return-Path: <
[email protected]>
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:
[email protected]
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: <
[email protected]>
Comment: Virus Discussion List
Originator:
[email protected]
Errors-To:
[email protected]
Reply-To: <
[email protected]>
Sender:
[email protected]
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
>From: "Kenneth R. van Wyk" <
[email protected]>
To: Multiple recipients of list <
[email protected]>
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
[email protected].
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:
<
[email protected]>.
Ken van Wyk
----------------------------------------------------------------------
Date: Thu, 19 Nov 92 23:17:45 +0000
>From:
[email protected] (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 <
[email protected]>
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)
[email protected] or
[email protected]
------------------------------
Date: Fri, 20 Nov 92 03:49:33 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: KEY Press virus & McAfee v97 (PC)
Hello Vesselin,
[email protected] (Vesselin Bontchev) writes:
>
[email protected] (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 "
[email protected]" 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 |
[email protected]
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:
[email protected] (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:
[email protected] (Paul Ducklin)
Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)
Thus spake
[email protected] (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
[email protected]
CSIR Computer Virus Research Lab * Box 395 * Pretoria * 0001 S Africa
------------------------------
Date: Fri, 20 Nov 92 08:42:33 -0600
>From: Jim Erickson <
[email protected]>
Subject: Re: F-PROT question (PC)
[email protected] (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." <
[email protected]>
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:
[email protected]
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:
[email protected]
BITNET:
[email protected]
------------------------------
Date: 20 Nov 92 22:34:38 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: SCAN 95b doesn't find MtE in EXE files (PC)
[email protected] (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:
[email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: 20 Nov 92 22:44:43 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: VSUM Listing (PC)
[email protected] (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:
[email protected] D-2000 Hamburg 54, Germany
------------------------------
Date: 20 Nov 92 14:59:35 +0000
>From:
[email protected] (Christer Olsson)
Subject: Re: SCAN 97 not working on OS/2 (OS/2)
[email protected] (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:
[email protected] (Kevin Marcus)
Subject: Re: Things that keep me awake at night
[email protected] (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:
[email protected] (McAfee Associates)
Subject: Re: Being forthcoming...
Hello Tarkan,
[email protected] (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 |
[email protected]
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 <
[email protected]>
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:
[email protected] (Gary Heston)
Subject: Re: Things that keep me awake at night
[email protected] (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.
[email protected] 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:
[email protected] (Valdis Kletnieks)
Subject: Re: Things that keep me awake at night
[email protected] (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 <
[email protected]>
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
[email protected]
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)
[email protected],
[email protected]
Work (205)348-3968 fax (205)348-3993
------------------------------
Date: Thu, 19 Nov 92 22:09:05 -0500
>From: James Ford <
[email protected]>
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)
[email protected],
[email protected]
Work (205)348-3968 fax (205)348-3993
------------------------------
Date: Fri, 20 Nov 92 15:13:03 -0800
>From:
[email protected]
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
[email protected] | You realize, of
Institute for
[email protected] | course, that these
Research into
[email protected] | new facts do not
User
[email protected] | coincide with my
Security Canada V7K 2G6 | preconceived ideas
------------------------------
Date: 02 Nov 92 18:12:38 +0000
>From:
[email protected] (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:
[email protected] 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
