Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.sys.ibm.pc,sci.crypt Subject: Re: Stopping Trojans Message-ID: <5760@brl-smoke.ARPA> Date: Tue, 14-Apr-87 10:10:20 EST Article-I.D.: brl-smok.5760 Posted: Tue Apr 14 10:10:20 1987 Date-Received: Sat, 18-Apr-87 23:47:50 EST References: <537@faline.bellcore.com> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 16 Xref: mnetor comp.sys.ibm.pc:3328 sci.crypt:336 In article <537@faline.bellcore.com> karn@faline.bellcore.com (Phil R. Karn) writes: >I've read one too many Trojan Horse reports. I'm tired of hearing about >people having their hard disks wiped out by jerks with a strange sense of >humor. They must come from the same crowd that puts cyanide into Tylenol. Or people who think "practical jokes" are funny. >I think I have a possible technical solution to the problem. It looks okay, if everybody would agree to use the same algorithm. Just make sure that the width of the checksum data flow is great enough through the entire algorithm that the postulated malicious person could not simply adjust a small number (e.g. 16-bit datum) in one block of the file until the computed checksum came out right. 64 bits (assuming DES one-way functions) is probably enough to foil virtually all would-be troublemakers for the near future.