Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!pesnta!amd!amdcad!cae780!leadsv!rtgvax!ramin From: ramin@rtgvax.UUCP Newsgroups: net.crypt Subject: Decryption of corrupted files... Message-ID: <60@rtgvax.UUCP> Date: Wed, 30-Apr-86 16:21:22 EDT Article-I.D.: rtgvax.60 Posted: Wed Apr 30 16:21:22 1986 Date-Received: Sat, 3-May-86 17:49:47 EDT Organization: Erewhon Travel Lines: 98 Keywords: I'm not paranoid, but my secret twin brother...? [ eat hot deathly cipher... aaarrrg Here's a nice 'n juicy one... I have a problem to which all suggestions and flames are welcome... The program under question is a file encryption routine I wrote years ago under VMS 3.x in VMS assembler. It incorporates a block AND record chaining encryption method. The actual encryption engine uses the VAX cyclic redundancy check instruction (CRC) with large prime coefficients and a number of other convolutions (reversible, naturally...). This was done at a time when VMS had absolutely NO encryption facilities and one was sorely needed for private files. To dissuade people from copying the ciphertext file to try to break it by trial and error, I also encrypted the file id and added a single line-header to the ciphertext file (i.e. not to even TRY decoding if the file-id is different but allowing for a backup mechanism when files are backed-up and recopied) along with a few other info (a seed value taken from the system clock, a CRC checksum on the ciphertext, the encryption mode for sizes less than one block, etc...). The CRC scheme, though probably not anything as involved as the heavy-duty encryption routines out there was very fast and showed very little convergence under alternate (but close) keywords. The distribution of ciphertext ascii bytes was also quite nice... This system has worked quite well for some years. Until a few weeks ago I encrypted some LISP, C, and MACRO source programs I had been working on in my own time. I also decrypted them several times afterward to make a few changes. Yesterday I tried decrypting some files to start porting them to un*x, but sadly the checksum failed. I have a command qualifier that bypasses the checksum and the file decrypted successfully. When looking at the cleartext result, I found very spurious ascii characters mostly in the high end (i.e. 8th bit set). About 80 percent of the cleartext was fine but then a series of garbage characters would take over and no more than two lines later, the cleartext would proceed. Very little connection was observed between the type of garbage (i.e. #include at the beginning of file mapped to different garbage than #include in the middle of the file). I suspect this is because of the chaining... Now my question is what method would anyone suggest in recovering ciphertext files that have been corrupted accidentally (i.e. either through disk or tape errors and/or malicious tampering (:-). I presume this is the case for most people, that once one encrypts a file one doesn't leave the cleartext file sitting around and usually there's only one copy of the ciphertext file... (In my case, I took printouts of the final programs home so I managed to recover everything but my pride (:-) The implication here is that unlike network error-correcting schemes there is no possibility of a "retry" transmission. In my case, I could have made the encryption program write to disk and read it back for verification, but remember that the corruption happened several days after the file had even been touched... I suppose I could include the header in a separate "central" header-file facility but I think keeping them together lends itself to moving it around easily and what if the header-file becomes corrupted (ouch!) My current inclination is compartmentalization (phew!) i.e., to separate a file into user-definable "pages" with different granularities (i.e. every n bytes) which would be separately encrypted with different checksums and all, with chaining starting at a fixed point and ending at a fixed point and then restarting again with a new value. In this way damage to the "entire" file would be avoided, and would not carry forth due to chaining to the rest of the file. I was lucky this time... what if someone gets ALL garbage and no printouts? This still fails to address a "recovery" scheme from such errors... Any ideas out there? I think I could no longer enforce the problem parameter that the ciphertext file be as close to cleartext in size as possible... i.e. not allowing control mechanisms into the file is over-optimistic. I certainly hope this is trivial (and if it is, it's back to the drawing board...) Any references to sources would also be welcome... I will repost any replies and/or references, and as soon as I'm done reading the references, the results from that if anyone is interested... Sorry this is so long but I thought the problem is general enough and merits at least SOME communal brainstorming... Looking forward to suggestions... ramin -- =--------------------------------------=-------------------------------------= : alias: ramin firoozye' : USps: Systems Control Inc. : : uucp: ...!shasta \ : 1801 Page Mill Road : : ...!lll-lcc \ : Palo Alto, CA 94303 : : ...!ihnp4 \...!ramin@rtgvax : ^G: (415) 494-1165 x-1777 : =--------------------------------------=-------------------------------------=