home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / virus / 4876 < prev    next >
Encoding:
Internet Message Format  |  1993-01-12  |  3.2 KB
  1. Path: sparky!uunet!spool.mu.edu!uwm.edu!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!news.sei.cmu.edu!cert!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
  5. Message-ID: <0003.9301121242.AA22066@barnabas.cert.org>
  6. Date: 7 Jan 93 14:59:12 GMT
  7. Sender: virus-l@lehigh.edu
  8. Lines: 61
  9. Approved: news@netnews.cc.lehigh.edu
  10.  
  11.  
  12.   In reply to me, Vesselin Bontchev writes:
  13. >>          First, you write as if all algorithms have a seed.
  14. >
  15. > My initial thought was that the database of checksums is kept on-line.
  16. > If it isn't (i.e., if it is stored on a write-protected diskette),
  17. > then you don't need any cryptographic checksum, of course. But if it
  18. > is, you cannot just use plain MDx or any other known keyless
  19. > algorithm, because a virus could use the same algorithm to compute the
  20. > new checksum of the infected file and update the database of checksums,
  21. > so that everything will look OK... In these cases, you -must- have
  22. > some kind of key that is kept unknown to the virus.
  23.  
  24. Since this is essentially the same as what I have written several times,
  25. I guess I can't very well object to it, can I?  :-)
  26.  
  27. >>                 But what do you mean by "using a different seed for
  28. >> the checksum" in the case of CRC?
  29. >
  30. > Well, a CRC is usually computer like this:
  31. >
  32. >     crc = INITIAL_VALUE;
  33. >       while ((c = getc (file)) != EOF)
  34. >        crc = crc_table [(crc & 0x00FF) ^ c] ^ (crc >> 8);
  35. >
  36. > Usually INITIAL_VALUE is 0, but you could set it to anything you would
  37. > like...
  38.  
  39. Well, I think that comes from using a particular (table-driven) *im-
  40. plementation* of CRC, and is not an essential feature of CRC as it
  41. is defined.  Also, while I agree that in this implementation
  42. INITIAL_VALUE could be considered as a seed, I doubt that varying this
  43. value adds any security, since CRC can be made key-dependent in a
  44. very natural way (by varying the generator) and since, in a certain
  45. sense, it is then provably secure (subject to certain reasonable
  46. assumptions).
  47.  
  48. >>   More important, in the case of MDx and X9.9, how do you know that
  49. >> varying the seed is enough?
  50. >
  51. >You are right, I don't know whether it is secure enough. But you have
  52. >to do something with the keyless algorithms, if you want to achieve
  53. >different checksums for each user and not allow the virus to guess the
  54. >correct checksum of the modified object...
  55.  
  56. But why is it necessary to do something with keyless algorithms at
  57. all?  There is an alternative to varying a seed (or artificially
  58. introducing a key) in a keyless algorithm, and that is to use an
  59. algorithm which is key-dependent by its very design (such as the MAA
  60. of ISO 8731-2 or ANSI X9.9, if one wants a cryptographic algorithm).
  61.   I'm not saying that the latter alternative is necessarily better
  62. than the former.  Regardless of which is used, the important criteria
  63. are security and speed, where "security" means mainly the requirement
  64. that, given a file (without knowledge of the key or seed), it be com-
  65. putationally infeasible to create another file with the same checksum
  66. as the given one.
  67.  
  68.                                      Y. Radai
  69.                                      Hebrew Univ. of Jerusalem, Israel
  70.                                      RADAI@HUJIVMS.BITNET
  71.                                      RADAI@VMS.HUJI.AC.IL
  72.