home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / virus / 4761 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  2.8 KB
  1. Path: sparky!uunet!think.com!yale.edu!jvnc.net!netnews.upenn.edu!netnews.cc.lehigh.edu!news
  2. From: RADAI@vms.huji.ac.il (Y. Radai)
  3. Newsgroups: comp.virus
  4. Subject: Re: Integrity Management (PC)
  5. Message-ID: <0009.9212212018.AA02123@barnabas.cert.org>
  6. Date: 18 Dec 92 17:35:58 GMT
  7. Sender: virus-l@lehigh.edu
  8. Lines: 44
  9. Approved: news@netnews.cc.lehigh.edu
  10.  
  11.  
  12.   Padgett Petersen wrote:
  13. >> I agree but take it one step further, again the algorithm should be
  14. >> tailored to the specific machine and use a different seed on each - this
  15. >> in no way weakens the algorithm but gives each PC a different signature
  16. >> for a particular file. Break one machine and "malware" must start all over
  17. >> again on the next.
  18.  
  19.   Vesselin Bontchev replies:
  20. > In fact, it depends on the algorithm used. If you are using a CRC,
  21. > just using a different seed for the checksum does not make it secure -
  22. > you must change the polynomial each time. If you are using something
  23. > cryptographically strong as DES, MD4, MD5, MD2, or some such, then
  24. > just changing the seed is enough.
  25.  
  26. I agree with part of this.  Yes, it depends on the algorithm, and
  27. using a different seed does not necessarily make an algorithm secure.
  28. To give an example, if you alter the seed of a simple checksum
  29. algorithm (in the literal sense of "sum") from 0 to something unique
  30. to each computer, it's just as easy to forge checksums as with a
  31. fixed seed of 0.
  32.   However, I have a couple of minor quibbles with the rest of the
  33. paragraph (let's call it "hair splitting"; I'm tired of "nit pick-
  34. ing").  First, you write as if all algorithms have a seed.  Well, in
  35. the case of the MDx algorithms, I suppose you could say that the
  36. initial contents of the buffers constitute a seed; also that DES has a
  37. seed when used for authentication purposes (ANSI X9.9), namely the
  38. initial block.  But what do you mean by "using a different seed for
  39. the checksum" in the case of CRC?
  40.   More important, in the case of MDx and X9.9, how do you know that
  41. varying the seed is enough?  You *may* be right, but to the best of my
  42. knowledge, neither the buffer contents of MDx nor the initial block of
  43. X9.9 were designed for that purpose.  Notice in the case of X9.9 that
  44. security against forging is obtained, not by varying the seed (initial
  45. block), but by each user using a different (unknown) *key*.  So with
  46. MDx, varying the seed is probably *not* the most secure approach.  One
  47. obvious possibility would be to encrypt the message digest with a
  48. user-dependent secret key, but that would add a lot of time.  Maybe
  49. there's an equally secure method which does not take as much time.
  50.  
  51.                                      Y. Radai
  52.                                      Hebrew Univ. of Jerusalem, Israel
  53.                                      RADAI@HUJIVMS.BITNET
  54.                                      RADAI@VMS.HUJI.AC.IL
  55.