Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!dayton!meccts!viper!ddb
From: ddb@viper.UUCP
Newsgroups: comp.sys.ibm.pc,sci.crypt
Subject: Re: Stopping Trojans
Message-ID: <851@viper.UUCP>
Date: Wed, 15-Apr-87 16:25:59 EST
Article-I.D.: viper.851
Posted: Wed Apr 15 16:25:59 1987
Date-Received: Sat, 18-Apr-87 01:04:22 EST
References: <537@faline.bellcore.com>
Reply-To: ddb@viper.UUCP (David Dyer-Bennet)
Organization: Terrabit Software
Lines: 28
Xref: utgpu comp.sys.ibm.pc:2965 sci.crypt:315


Your suggestion of using DES in a checksum algorithm sounds like overkill to
me.  The normal crc-16 algorithm is sufficiently hard to patch around for this
purpose.  And ARC and company already report it in their verbose directories.  
This reduces the problem to distribution of the correct CRC's.

I have a modest proposal for that -- using the public-key cryptosystem 
shareware, the author of each shareware package would include a "signed"
message giving the correct checksums for the product he was distributing.
Now we've reduced the problem to distributing the public keys from the 
shareware authors.  This is easier than distributing the current checksums,
because it would be invariant across versions.  It would be possible to set
up some sort of a public key server on Fidonet with reasonable security --
the problem can be reduced to the step of distributing the public key of
the public key server.  That's just ONE key (of perhaps 150 digits) that
has to be widely and accurately distributed.

(Even if the crc-16 algorithm isn't sufficient, I think this public
encryption approach is a better way to distribute the correct checksums
than publication in byte or whatever.  Besides, they'd put it on Bix and
compuserve and stuff I don't want to spend money on.)

 
-- 
David Dyer-Bennet
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!ddb
UUCP: ...ihnp4!umn-cs!starfire!ddb
Fido: sysop of fido 14/341, (612) 721-8967