Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!husc6!panda!genrad!decvax!decwrl!glacier!kestrel!king
From: king@kestrel.UUCP
Newsgroups: net.crypt
Subject: Re: Decryption of corrupted files...
Message-ID: <7987@kestrel.ARPA>
Date: Tue, 13-May-86 15:36:07 EDT
Article-I.D.: kestrel.7987
Posted: Tue May 13 15:36:07 1986
Date-Received: Fri, 16-May-86 02:09:30 EDT
Organization: Kestrel Institute, Palo Alto, CA
Lines: 27


   From: gnu@hoptoad.uucp (John Gilmore)
   Newsgroups: net.crypt
   Date: 3 May 86 12:20:42 GMT

   The traditional way to improve data reliability when there is no chance
   to recover the data is called "forward error correction".  It adds some
   redundant data to the message.  This kind of thing will be used in
   Stargate for example, since you can't ask the satellite to send it
   again please over a receive-only link.  Disk error correcting codes
   are like this too (Fire codes).

   But:  Any kind of redundancy you put in your cleartext (or enciphering
   algorithm) will cause it to be easier to break.  A simple example.
   Let's say you put a parity bit in each character before encrypting.  A
   code-breaker who tried a key that produced bad parity characters would
   know that that was the wrong key.  Knowing this, and the enciphering
   algorithm, lets a codebreaker eliminate a lot of possible keys quickly.

   There's probably no simple way to make your data both easier to recover
   (for you) and harder to recover (for a codebreaker).
   -- 
   John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa

Wouldn't it be better to put on the error correction AFTER the
encryption?

-dick