Path: utzoo!yunexus!ists!jarvis.csri.toronto.edu!mailrus!accuvax.nwu.edu!tank!eecae!netnews.upenn.edu!vax1.cc.lehigh.edu!sei.cmu.edu!krvw From: XRAYSROK@SBCCVM.BITNET (Steve Woronick) Newsgroups: comp.virus Subject: Re: Signature Programs Message-ID: <0007.8911171251.AA11880@ge.sei.cmu.edu> Date: 17 Nov 89 05:17:27 GMT Article-I.D.: ge.0007.8911171251.AA11880 Sender: Virus Discussion List Lines: 76 Approved: krvw@sei.cmu.edu Bob Bosen <71435.1777@CompuServe.COM> brings up some interesting points, asking why programmers writing authentification programs are utilizing CRC and checksum algorithms rather than more sophisticated algorithms like ANSI X9.9, ISO 8731-2, or DES. I think it depends on what you are trying to do. If your plan is to encrypt your program and rely on difficulties in decryption for protection against infection, then it probably makes sense to use something very sophisticated, because you want to make certain that no one but yourself can do the decryption. If you are leaving the encrypted form on your disk (where it might be compared with the unencrypted form which is surely to appear either on your disk or in memory at some future date if you use it), you don't want to be using something so simple that it might give your algorithm away. On the other hand, if you are not encrypting your program but are simply trying to generate a number (or maybe several numbers) for authentification purposes, I don't see that it is necessary to use anything more sophisticated than a polynomial. If the virus doesn't know your polynomial, then it's chances of guessing a sequence of characters with which to "pad" your program file in order to generate the same CRC value as the original unaltered program is quite small. Of course, everyone ought to be using a slightly different algorithm (i.e. different polynomials) and ought to be hiding the authentification algorithm. Correct me if I'm wrong: If the algorithm is sophisticated enough that it is very hard for anyone to guess CRC values, then there probably is no need to hide the values it calculates for each of your program files; in principle, one might be able to deduce the algorithm by comparing program files with the CRC values generated by the algorithm, but this will work only if there is enough information available for analysis (which will not be the case for sufficiently high order polynomials). The information in a CRC is small compared to the information in an encrypted file, so CRC programs need not be terribly sophisticated to foil discovery. It has been pointed out that doing a cold boot from a clean floppy assures you that your system is running clean (i.e. there are no viruses in memory --- there may be some on your hard disk, but these are dormant until you run an infected program). If you then run your authentification program from the clean floppy disk on your clean system to check your hard disk (or other), you can rest fully assured that no virus etc. has had the opportunity to intercept your checking program and fool you into thinking that an infected program is uninfected (unless you were dumb and previously exposed the clean disk, though write- protected, to the inquiring eyes of a virus). And since there are no viruses in memory, none can steal your checking algorithm or any of the CRC values (which you probably are keeping on the clean disk; for that matter you can keep your own personal polynomial coefficients on the disk also). You probably will wisely want to keep your clean disk write-locked to prevent accidents, but infection is not the only threat (so write protection does not fully protect one from accidents). If one runs the authentification program (or even accesses the disk it's on), without first doing the cold clean boot, then one risks having the authentification algorithm stolen by a virus. And as has been stated before, one cannot be certain of the authentification results if the cold boot from the clean disk was not done. Finally, you obviously have to write to the clean disk once in a while to update the CRC-values list for new programs/ whatever, but this is no problem because you're not going access it without first doing the cold clean boot. One of course also assumes that your clean disk was really clean to start with. Any comments? Here's a question: What's a good reference for finding out about ANSI X9.9 and ISO 8731-2? I can give you one for DES (Data Encryption Standard): Numerical Recipes, The Art of Scientific Computing, by W.H. Press, B.P. Flannery, S.A. Teukolsky, and W.T. Vetterling, published by Cambridge University Press, (c)1986, p. 214-220. Two and one half pages of highly-inefficiently coded FORTRAN is given which implements the DES algorithm (except that the standard itself explicitly states that any implementation in software is not secure and therefore not DES). - ----------------------------------------------------------------------- Steven C. Woronick | Disclaimer: These are my own opinions. Physics Dept. | Always check it out for yourself... SUNY at Stony Brook | Stony Brook, NY 11794 | Acknowledge-To: