VIRUS-L Digest Thursday, 25 Jan 1990 Volume 3 : Issue 22 Today's Topics: Re: Internet worm writer to go to trial Jan 16th. (Internet) Re: Universal virus detection Disinfectant versions (Mac) STONED virus in LRS lab at Univ. of Guelph (PC) "Desktop Fractal Design System Not Infected" Submission for comp-virus Jerusalem Virus (PC)! Trial & Double Standard Signature Programs Signature Programs Signature Programs Practical a-priori viruscan? Signature Programs 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., and sent to VIRUS-L@IBM1.CC.LEHIGH.EDU (that's LEHIIBM1.BITNET for BITNET folks). Information on accessing anti-virus, document, and back-issue archives is distributed periodically on the list. Administrative mail (comments, suggestions, and so forth) should be sent to me at: krvw@SEI.CMU.EDU. - Ken van Wyk --------------------------------------------------------------------------- Date: 25 Jan 90 15:23:08 +0000 From: spaf@cs.purdue.edu (Gene Spafford) Subject: Re: Internet worm writer to go to trial Jan 16th. (Internet) gwishon@BLACKBIRD.AFIT.AF.MIL (Gordon D. Wishon) writes: >Gene, in your report (_The Internet Worm Program: An Analysis_), you >speculated that the code may have been written by more than one >person. Has anything come out in the trial to support this? To my knowledge, nothing came out in the trial about this. I do know, however, that the password cracking code in the Worm was not written by Mr. Morris. He obtained that code when he spent a summer at Bell Labs. It was part of a security testing package written by other people, and it appears that he made a copy he had access to. I also suspect that he got the code to break "fingerd" from someone else, but he would have to comment on that. - -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-2004 Internet: spaf@cs.purdue.edu uucp: ...!{decwrl,gatech,ucbvax}!purdue!spaf ------------------------------ Date: 25 Jan 90 08:21:50 +0000 From: jc@atcmp.nl (jc van Winkel) Subject: Re: Universal virus detection There are a few points I think that should be made. Let's (for the sake of argument) assume that the undecidability proof is valid. This only implies that a virus detector will not be able to 1) catch all viruses or 2) 'find' a virus in an uninfected program. It does not say anything about percentages, just that it MAY happen that a wrong conclusion is drawn. All current viruses can be detected by either appearance or by behavior. For all current viruses: Once you know its structure, you can detect it. (Take a look at the biological analogy: We can detect almost all biological viruses that are known, but it is IMPOSSIBLE to detect viruses that have not yet emerged. If a new virus was synthesized, either by mutation (which happens all the time), or by man (I don't like the thought) we would only be able to detect it if it shared some characteristics with known viruses. If the virus is too new, we can only conclude that someone has cought a desease that is unknown to man. Now for my second point: It is also indecidable for a virus to see whether or not a program is a virus detector. The informal proof runs along the same path as the informal virus detection proof. In the virus detection proof, use is made of the fact that the virus 'knows' that a program is a detector. Yet, this is indecidable, so not all hope is lost... There are many more proofs of indecidability, Prof Cohen mentioned them in his Thesis. They are: Detection of viruses by appearance. Detection of viruses by behavior. Detection of evolution of a known virus. Detection of viruses by appearance. Detection of triggering mechanisms by appearance. Detection of triggering mechanisms by behavior. Detection of evolution of a known triggering mechanism . Detection of virus detectors by appearance. Detection of virus detectors by behavior. Detection of evolution of a known virus detectors. Although this theoretical discussion is interesting, I think that with some measures we can get pretty safe computing! Using a decent file access control mechanism and not letting anyone write to a file that is executable, but reserving that right to programs with 'compiler' or 'linker' status will make viruses very hard to write. These are my own ideas, not necessarily my employer's ------------------------------ Date: Thu, 25 Jan 90 09:47:00 -0600 From: "David D. Grisham" Subject: Disinfectant versions (Mac) This was cross posted to: Newsgroups: comp.sys.mac Subject: Re: Disinfectant 1.6 Summary: No version 1.6 References: <25b594c61b1@vms.huji.ac.il> <2003@tellab5.TELLABS.COM> Followup-To: Jeff Wiseman's note This is probably a typo. However, there is _NO_ version 1.6 of Disinfectant! If you have one let me or John Norstad know immediately. dave _In art <2003@tellab5.TELLABS.COM> wiseman@tellab5.UUCP (Jeff Wiseman) writes: _>In article <25b594c61b1@vms.huji.ac.il> RWERMAN@vms.huji.ac.il writes: _>> I have enjoyed using Disinfectant in it's earlier versions but _>>since downloading version 1.6 [including WDEF virus protection], it ^^^^^^^^^^^^^ NO Such Version! _>>refuses to pass ANY of my files. Any suggestions? Thanks. _>Quarantine your Mac?? _>(Sorry Bob, I suppose it isn't funny but I couldn't resist :-) _>-- _>Jeff Wiseman: ....uunet!tellab5!wiseman OR wiseman@TELLABS.COM ------------------------------ Date: Thu, 25 Jan 90 14:01:34 -0500 From: Peter Jaspers-Fayer Subject: STONED virus in LRS lab at Univ. of Guelph (PC) We have the Stoned virus here (trademark msg "Your PC is now stoned!" upon boot). It has appeared in one lab only (so far). Novell. They boot from floppy (strange, I thought "stoned" infected partition sectors of hard disks, so why msgs upon floppy boot?), and McAfee's SCAN flags the floppies as being infected in the boot sector. OK, so I'm wrong. Anyhow: 1> Effects of this virus (how dangerous?)? 2> Complete documentation on this virus is available from? 3> Disinfectors available? (pls not SIMTEL, I can never get on SIMTEL20) 4> Helllpp! /PJ SofPJF@VM.UoGuelph.Ca ------------------------------- If you try to please everyone, somebody is not going to like it. ------------------------------ Date: Thu, 25 Jan 90 10:44:09 -0500 From: Eric Roskos Subject: "Desktop Fractal Design System Not Infected" This is a follow-up to my 1/12/90 posting in which I observed that I had bought and used a copy of the Desktop Fractal Design System allegedly infected with the "1813" virus, but had not seen any problems. I have since looked more closely at my executables, which are said to increase in size as a result of this virus, and have also run the virus-scan program from SIMTEL20 on the original disk. My executables do not increase in size, and the original disk does not show the presence of any virus when checked with this program. I also have not seen any abnormal behavior such as was described as being caused by this virus, while using the system for very heavy software development during this month. >From the evidence presented on VIRUS-L to date, it appears that of a sample size of two, one copy was infected, and one was not. It would appear that a larger sample would be helpful in order to understand this problem. - -- Eric Roskos (roskos@IDA.ORG or Roskos@DOCKMASTER.NCSC.MIL) ------------------------------ Date: 25 Jan 90 20:41:41 +0000 From: mmccann@hubcap.clemson.edu (Mike McCann), mmccann@hubcap.clemson.edu (Mike McCann) Subject: Submission for comp-virus WDEF at Clemson University For those of you who have an interest in these things... The WDEF Mac virus has reached Clemson University (after UNC Chapel Hill, where else could it go?). GateKeeper Aid is working fine for all those people who chose to take my advise and install it. Happy virus hunting, - -- Mike McCann (803) 656-3714 Internet = mmccann@hubcap.clemson.edu Poole Computer Center (Box P-21) Bitnet = mmccann@clemson.bitnet Clemson University Clemson, S.C. 29634-2803 DISCLAIMER = I speak only for myself. ------------------------------ Date: Thu, 25 Jan 90 15:59:00 -0400 From: Michael Greve Subject: Jerusalem Virus (PC)! We recently discovered the Jerusalem A virus attached to a program on a office machine. I have a couple questions. 1. What does this virus do and how does it infect? and 2. How does one go about getting rid of the virus. We have Viruscan, which is how we detected the virus, but we have no way of getting rid of PC viruses. This is our first PC virus. I guess we're in the big time now!!!! Michael Greve University of Pa. Wharton Computing greve@wharton.upenn.edu ------------------------------ Date: 25 Jan 90 11:27:10 -0500 From: Bob Bosen <71435.1777@CompuServe.COM> Subject: Trial & Double Standard Now that a jury has determined that Robert Morris Jr. was guilty of a crime when he wrote and unleashed the famous "Internet Virus", it is time to consider the implications of the punishment that society will exact from him. It's also time to examine society's motives in inflicting and publicizing such punishment. Obviously, if punishing young Morris can deter others from attempting similar nefarious activities, society can derive some benefit. There are those who advocate severe and widely publicized penalties. On the other hand, there are others who suggest that a medal of commendation may be more appropriate. It is unusual to hear such wide-ranging controversy regarding appropriate punishment after a trial. May I suggest some reasons for the controversy? I postulate that the computer world has been attempting to cheat on the rest of society. For thousands of years, human society (in the form of business, banking, and government) has developed a clear notion of generally accepted practices that defines prudent management and handling of responsibility. These standards evolved out of necessity: no single person or organization can bear the cost of protecting himself from crime by himself. Trying to anticipate all the kinds of crimes and trying to get ironclad protection mechanisms into place beforehand has proven impossible. Therefore, instead of attempting "perfect" security systems, society has said "We will share this burden with you if you will follow generally accepted practices." Our judicial system and our civil law enforcement agencies are the result. But these agencies cannot function and should not protect those who do not accept their portion of the responsibility. This means abiding by the law and meeting the requirements of generally accepted practice. Long before computers and computer crime, businesses learned that they could not afford to fully protect themselves from their own employees. It is simply impossible to hire enough guards, to buy enough alarms, or to build enough walls. Instead, for thousands of years, business has relied upon the practice of "auditing". Individual Accountability has become the generally accepted means by which banks, businesses, and governments have carried out their responsibilities to themselves, to each other, and to society. I postulate that use of a computer does not grant license to disregard thousands of years of generally accepted practice. But it is clear that the computing community has attempted to live outside this norm for the past 30 years. The Internet virus is but the most recent spectacular event to illustrate how far outside the mainstream of business practice our integrated computer systems have been built. If young Morris had believed he would be held accountable for his actions, he probably would not have attempted his crime. But a key fact revealed in the Morris case proves that the controls that Cornell University thought were in place to "secure" their computers could not be relied upon to hold users accountable for their actions. Computer records controlled by Morris contained the user names and passwords used by hundreds of other users. Whoever obtained these could have successfully masqueraded under any of the corresponding identities. This lets all users of Cornell systems off the hook. This is best illustrated by the following example: Suppose you are a graduate student of computer science at Cornell. You would never think of committing a computer crime, and have never done so. You are careful with your handling of your passwords, and you change them every month without exception. One day, you are summoned to the office of campus security, and upon your arrival you notice that the head of Data Processing is present, as well as the university's attorney. They inform you that several irregularities have been occuring on the computer systems you use, and that your user name and password have appeared in audits directly associated with these events. Perhaps criminal activities have taken place. Your academic standing, career, and good name are at stake. You have perhaps 5 minutes to persuade these people of your innocence or you may find yourself in court. What do you say? You could proceed along these lines: "I didn't do these things. I know I didn't do these things, and if you'll think for a minute about the computers and networks you force me to use and the way my password traverses them, you'll see that there is no way you can hold me accountable for these problems. The personal computers I use are not mine, and are not under my control. The PC maintenance people and DOS gurus that frequent this campus could easily have trapped my passwords at any of several levels where they must traverse equipment and software that is under THEIR control, not mine. It's YOUR Local Area Network, not mine. It's YOUR minicomputers, YOUR data communication controllers, YOUR multiplexers, YOUR Wide Area Netoworks, YOUR UNIX gurus, YOUR VTAM people, YOUR MVS experts, and YOUR programmers who determine what happens to my password. I am given no opportunity to protect my password once it leaves my fingertips. Robert Morris was able to collect hundreds of passwords from users all around this campus, and this proves that the problems you are attempting to pin on me could have been caused by any of hundreds of different people. You can't pin this on me!" And of course, you'd be right. The problem is that memorized passwords can not be relied upon to hold users accountable for their actions in todays's environment of Integrated Systems. There are too many places in our networked, integrated environment where insiders are routinely exposed to passwords. Indeed, it is not unusual for tens of thousands of copies of passwords to be made, retained, and broadcast during each month of routine use. I am NOT saying that a large proportion of these exposures are actually exploited. I AM saying that the mere PROBABILITY of password exposure eliminates the POSSIBILITY of user ACCOUNTABILITY. Why is this situation tolerated in the computing community when equivalent situations are considered criminally negligent in the practices of the rest of society? Why don't bankers abandon the use of credit cards, photo IDs and signatures and just debit our bank accounts whenever a merchant tells them our passwords? It would be a lot easier. Imagine getting a letter from your bank along these lines: Dear esteemed depositor: As you know, for the past 15 years, you have been entrusted with our bank card, and have used it in your banking transactions. We are replacing your bank card with a password. You will no longer have to carry your bank card. Your new password is "FRED". Please keep it secret. Whenever you want to withdraw funds or make credit card purchases, just write FRED at the bottom of the invoice and we'll take care of the rest. If you ever suspect that anybody has found out your password, please drop drop us a post card with "FRED" crossed out in red pen and a new password of your choice written in blue ink. It is your responsibility to keep your password secret. You will be held accountable for any and all banking transactions that say FRED on them, including questionable or illegal transactions, for which you will be prosecuted to the full extent of the law. Computer professionals: does this sound painfully familiar? Why does this sound so silly in a banking or business context when it is so universally accepted if a computer is involved? Who is responsible for the perpetration of this double standard? Is it possible that the punishment of Robert Morris helps us all feel a little safer from the accusation that a large portion of the blame should rest with us? Bob Bosen Enigma Logic ------------------------------ Date: 25 Jan 90 11:23:16 -0500 From: Bob Bosen <71435.1777@CompuServe.COM> Subject: Signature Programs When I began this in-depth series of discussions on authentication algorithms and signature programs late last year, I was alarmed and frustrated by the lack of attention being paid to the subject of well- researched "standard" authentication algorithms. At this point I must say I am gratified by the response. We've heard from Ralph Merkle, Bill Murray, Jim Bidzos, Ross Greenberg, Y. Radai and others directly, and we've heard indirectly from Fred Cohen, Robert Jueneman, and Prof. Rabin. Obviously there are a lot of divergent interests and opinions represented here, but among all the disagreement I see emergent patterns that I consider very healthy. First, it is clear that the preponderance of expert opinion now favors increased use of algorithms that are more sophisticated than what I called "some programmer's guess" at an authentication algorithm. Second, it is clear that there are ways of "leveraging" the performance of these sophisticated authentication algorithms. As I pointed out in my original posting and as Jim Bidzos has further stressed, slow performance need not be a problem because it is not always necessary to apply the slower algorithms directly to the entire file in order to obtain a sophisticated signature: It is possible to combine two or more well-understood algorithms in order to obtain the advantages of each and the detriments of neither. Third, it is clear that the use of sophisticated algorithms allows functions and features, such as those suggested by Bill Murray (use of a MAC to ensure that programs are received as they were shipped) that would otherwise be impractical or untrustworthy. Thanks to all that have supported the need for using sophisticated authentication algorithms! - -Bob Bosen- Enigma Logic Inc. ------------------------------ Date: 25 Jan 90 11:24:23 -0500 From: Bob Bosen <71435.1777@CompuServe.COM> Subject: Signature Programs In his posting of Jan 4 '90, Y. Radai acknowledges that the added sophistication of X9.9 compared to CRC may be well worth the added time in the case of authentication of bank transfers or other conventional applications, and then asks me if I have ever considered the possibility that this sophistication might be wasted when dealing with viruses. Yes. Of course I have considered this possiblity. I considered it long and hard. I was forced to reach the same conclusion that bankers and businessmen reached when they insisted that sophisticated means be developed to protect their business transactions: Not all programs are video games. Some programs are important. Some programs, if attacked by a malicious virus or trojan horse, could pervert banking transactions or business balances. Some programs, if attacked, could place human lives at risk. We are not just talking about reformatting and restoring a hard disk here. I am convinced that businesses and governments need protection that is capable of resisting the attacks of a sophisticated insider who specifically targets high-value operations. Furthermore, I would like to postulate that the day may come when somebody in the anti-virus community will produce a really good defense mechanism that is practical, reliable, sensibly priced, and really worthy of widespread market acceptance. Perhaps two or three such excellent programs will emerge and distinguish themselves as the clear leaders. Each such program could eventually be installed on millions, or even tens of millions, of future computers. Let's hope it happens some day. And let's hope no virus writer is able to target one such market leader and forge signatures! Obviously in such a situation with millions of users, a protection mechanism would make a tempting target for skilled virus writers or trojan horse writers. In such a situation, it is entirely possible that criminals might NOT launch a widespread attack designed to spread to a large population. (That would reveal their skill and deprive them of the opportunity to profit from it.) They might instead confine the spread of their virus to a very specific population of familiar computers known to control great value. For these and other reasons, I must disagree with the opinions that Y. Radai enumerated in his posting and upon which he based his latest set of conclusions. Specifically, in his opinion (1), Mr. Radai says that a virus must perform all its work ... "on the computer which it's attacking and in a very short time". That is not necessarily true. In networked environments with shared file systems, (and especially if remote execution is available), viruses could execute on different computers and take as much time as they needed. Also, as pointed out by Bill Murray, viral infections during the process of software distribution may be done off-line at the convenience of the attackers. And it is not necessary for a virus to SUCCEED in performing all its work in a single very short attempt. A virus might divide its clandestine attempts into very small chunks that are attempted frequently enough to guarantee eventual success, but which do not result in any pollution of off-line storage unless defense mechanisms (presumably marginally sophisticated ones of the type Mr. Radai hopes will be sufficient) are successfully bypassed. I must also disagree with Mr. Radai's opinion (2), wherein he posits "By its very nature, a virus is designed to attack a large percentage of the users of a particular system." Why? What's to prevent a virus writer from launching a "surgical strike" against a small population of familiar computers that are known to control assets or information of great value? Once again, I think Mr. Radai's view of the world does not reflect the realities of business or criminal nature. To be sure, most of the viruses we've seen so far have behaved like little PAC-MAN games, gobbling up everything in sight. But how long will it be before this video-arcade mentality is outgrown? As to Mr. Radai's opinion (3), he says that "a virus writer is not in a position to know what checksum algorithms may be in use on the computers on which his virus is unleashed." That's true TODAY. In fact, TODAY, it's even worse than that. Most virus writers can safely assume that there is NO protection of any kind on the target computers. But if our society is ever going to overcome its current vulnerability, we'll need reliable, low-cost defense mechanisms that are worthy of widespread use. This implies a necessity for economies of scale. Therefore, this opinion (3) will not necessarily be true for very long. Let's HOPE that when we get to that point, the authentication algorithms used are more sophisticated than simple checksums! - -Bob Bosen- Enigma Logic ------------------------------ Date: 25 Jan 90 11:24:38 -0500 From: Bob Bosen <71435.1777@CompuServe.COM> Subject: Signature Programs Although I disagree with the opinions expressed at the beginning of Mr. Radai's posting of Jan. 4, 1990, I find his analysis of the trade-offs between algorithmic sophistication and performance useful. From what I've read in this forum of late, it does appear that Ross Greenberg and Y. Radai are at one end of this spectrum and that Bill Murray, Ralph Merkle, Jim Bidzos, Fred Cohen, and the others mentioned in Mr. Radai's Jan. 4 posting are more or less at the other end with me. (If I've misrepresented your views here, gentlemen, I hope you'll forgive and correct me for it. I'm reading between the lines.) - -Bob Bosen- Enigma Logic ------------------------------ Date: Thu, 25 Jan 90 16:47:50 -0400 From: GEORGE SVETLICHNY Subject: Practical a-priori viruscan? In Virus-L v3 issue20, russ@Alliant.COM (Russell McFatter) writes: >... > >All things considered, we can actually write a program that, given >a questionable bit of code, can give one of the following results: > >OK: this program is safe and will not infect other applications. >BAD: the target program could, under some unknown circumstances, > modify other applications. >INCONCLUSIVE: The target program either modifies executable code or > executes variable data. > >... The problem of viruses (or more generally, nasties) is mostly program semantics (what programs do) and human intent and only secondarily program syntax (how programs are written). Syntactic problems are decidable, semantic problems generally are not (in Turing machines, in finite-state machines they generally are but the decision procedures are very rarely practical). What Russel suggests is that there is a useful practical approximate syntactic solution to the semantic and intentional problem of nasties. I seriously doubt this. Up to now nasties have been a bit flamboyant and show-offish. Their more subdued versions would be identical to normal bugs. The same code in a spreadsheet program that causes it to erroneously recalculate every now and then is either a bug if the programmer did not intend it or a nasty if it was put in on purpose. Surely the "O.K." category doesn't mean "bug free" (wouldn't it be wonderful otherwise?). To be 100% OK the category can only include those programs that can be proved to be correct on the object-code level and this means practically no program at all. The third category is grossly underestimated. One need not write to the code segment or execute from the data segment to create a nasty that doesn't fall in the second category. There are serious dangers within the processor instruction set. Consider an unconditional jump to an address given by a register or memory content, extremely useful in dealing with jump tables. Now, from the purely syntactic point of view you can't tell where you are jumping to. You can jump to a nasty piece of code. This can be in a portion of the program that syntactically is identified as being constant data: message strings, global program constants, etc.. It can also be in a piece of syntactically identified and innocuous-looking code *displaced* by a byte or two. Clarifying: Suppose one has somewhere in the code a conditional jump, a "jmp nz" instruction. The syntactic analyzer looks down both branches and finds nothing suspicious. Now the z branch is dummy since the programmer made sure this condition never holds (semantics). The dummy branch looks innocuous to the syntactic analyzer but the same byte sequence *starting from the second byte* is a nasty piece of business. One enters this nasty code by a "jmp reg" instruction in some other part of the program. Wolf semantics in sheep sytax. Very well, you say, let's put "jmp reg" instructions on the suspect list, however the "jmp reg" instuction is equivalent to "push reg" followed by "ret". Hence all code that uses "push" and "ret" is suspect, and this includes practically all the useful software under the sun. What all this means is that an a-priori scan for nasties *has* to be smart enough to anlyze the consequences of "jmp reg" instuctions and their kin, to see that stack discipline is maintained, to analyze what gets pushed and poped and when this can become a code adress, etc. A lot of semantics to approximate by syntax. There is a biological analog to the "second byte" situation above. Some genes overlap with others, that is, a base-pair sequence ABC.DEF.G... codes for one protein (a triple of base pairs is a codon for an amino acid) while the *same* but phase-shifted sequence BCD.EFG.H.... codes for another protein and both are actually produced by the organism. It's rather remarkable that such "gene multiplexing" can produce two useful proteins. In machine language code one doesn't see such code multiplexing since it must be practically impossible to multiplex two useful code sequences this way, but one can easily multiplex "silly" with "nasty" code and use the silly to camouflage the nasty. (Detecting silliness is another semantic problem.) The "O.K." category is thus practically empty, the virus hackers will make sure that their creations don't fall in the "BAD" category by carefull programming, and the "INCONCLUSIVE" category must be enlarged to include nasty "semantically-driven" jumps and code-multiplexing as a possibility which makes it contain practically all useful programs. This is hardly a practical solution. The upshot of this is that unless one changes to radically diferent memory and processor architectures (hard-wired separation of code and data memory, rigid code boundaries, fixed-instruction-length processors, separate stack for "call" and "ret", explicit jump-table handling ... ) there is not much hope for an effective a-priori scanner for nasties. One will have to be content with a-posteriori scanners for known nasties and watchdog programs that report on suspicious activity (semantics) rather than try to detect suspicious structure (syntax). Beyond this there are of course the people problems that have to be dealt with by education, law, politics, psychology, etc. ---------------------------------------------------------------------- George Svetlichny | Multiplexed sentences: Department of Mathematics | Pontificia Universidade Catolica | What sort of feet are moldy? Rio de Janeiro, Brasil | Hats or tofee? Tar 'em, oldy! | usergsve@lncc.bitnet | ---------------------------------------------------------------------- ------------------------------ Date: 25 Jan 90 15:14:57 -0500 From: Bob Bosen <71435.1777@CompuServe.COM> Subject: Signature Programs In reading Ross Greenburg's recent comments on Signature Programs, and in trying to respond to his specific statements for me, it appears that he must have missed my original posting in which I explained ways by which it is possible to extract excellent performance from authentication means based on combinations of ANSI X9.9, ISO 8731-2, and conventional CRC techniques. (Jim Bidzos has recently described a similar technique which includes RSA authentication.) For the benefit of others who might have also missed that background, I'll repeat a brief summary here. It is possible to greatly leverage the performance of sophisticated authentication algorithms by carefully controlling certain factors. Among them are: 1- The PERCENTAGE of the file that is subjected to the sophisticated algorithm. This can sometimes be quite a small fraction of the whole file. (The remainder of the file can be processed by an industry- standard CRC algorithm. There are various techniques deriving from cryptology that can be used to cause the effects of the sophisticated algorithms to "ripple through" all the way to the final signature.) Properly implemented, these techniques can result in a reliable, virtually unforgeable signature that is calculated almost as quickly as a conventional CRC. 2- WHEN the signature is calculated. Obviously you can infuriate your users if you make them stand around twiddling their thumbs while all your files are authenticated in batch mode during the bootstrap process. On the other hand, if most authentication is done "on the fly" as programs are loaded, users hardly notice the delays. 3- How OFTEN the signatures are calculated. It really isn't necessary to recalculate each and every signature every day, or even every time a program is executed. Sensible authentication frequencies will depend on the work environment, presence of known threats, and the value of assets controlled, but may average once or twice a month in typical business environments. 4- The ALGORITHM chosen. Although its strength is not as well researched as DES, ISO 8731-2 has withstood at least some respectable public scrutiny, and runs at least ten times as fast as DES. Early indications are that SNEFRU is a very strong algorithm that is much faster than DES. RSA is much slower than DES. (And as I've consistently said since my earliest posting, CRCs of varying strengths are available and can be used in appropriate combinations with some of the more sophisticated algorithms to speed things up still further.) By judiciously balancing these variables, it is possible to create a fast, reliable, sophisticated system that performs so quickly that users hardly notice it. I have to agree with Ross Greenberg that a sophisticated algorithm that performs poorly won't get used at all, and is therefore worse than an unsophisticated algorithm. But I also know, from direct, first-hand experience, that we need not limit ourselves to thinking of sophisticated algorithms as being slow performers. All things considered, there is really no reason NOT to abandon the simplistic algorithms in favor of those that are likely to be beyond compromise by virus writers for several years to come. - -Bob Bosen- Enigma Logic ------------------------------ End of VIRUS-L Digest ********************* Downloaded From P-80 International Information Systems 304-744-2253