🚀 go-pugleaf

  Padgett Petersen wrote:
>> I agree but take it one step further, again the algorithm should be
>> tailored to the specific machine and use a different seed on each - this
>> in no way weakens the algorithm but gives each PC a different signature
>> for a particular file. Break one machine and "malware" must start all over
>> again on the next.

  Vesselin Bontchev replies:
> In fact, it depends on the algorithm used. If you are using a CRC,
> just using a different seed for the checksum does not make it secure -
> you must change the polynomial each time. If you are using something
> cryptographically strong as DES, MD4, MD5, MD2, or some such, then
> just changing the seed is enough.

I agree with part of this.  Yes, it depends on the algorithm, and
using a different seed does not necessarily make an algorithm secure.
To give an example, if you alter the seed of a simple checksum
algorithm (in the literal sense of "sum") from 0 to something unique
to each computer, it's just as easy to forge checksums as with a
fixed seed of 0.
  However, I have a couple of minor quibbles with the rest of the
paragraph (let's call it "hair splitting"; I'm tired of "nit pick-
ing").  First, you write as if all algorithms have a seed.  Well, in
the case of the MDx algorithms, I suppose you could say that the
initial contents of the buffers constitute a seed; also that DES has a
seed when used for authentication purposes (ANSI X9.9), namely the
initial block.  But what do you mean by "using a different seed for
the checksum" in the case of CRC?
  More important, in the case of MDx and X9.9, how do you know that
varying the seed is enough?  You *may* be right, but to the best of my
knowledge, neither the buffer contents of MDx nor the initial block of
X9.9 were designed for that purpose.  Notice in the case of X9.9 that
security against forging is obtained, not by varying the seed (initial
block), but by each user using a different (unknown) *key*.  So with
MDx, varying the seed is probably *not* the most secure approach.  One
obvious possibility would be to encrypt the message digest with a
user-dependent secret key, but that would add a lot of time.  Maybe
there's an equally secure method which does not take as much time.

                                     Y. Radai
                                     Hebrew Univ. of Jerusalem, Israel
                                     RADAI@HUJIVMS.BITNET
                                     RADAI@VMS.HUJI.AC.IL