CFR2D2.DO by James Main Kenney 1997 Part 2 (of 5) documentation for encryption program CFRJMK version 2.0 (CFRT20.BA for the Tandy Radio Shack TRS-80 Model 100/102/200; CFRN20.BA for the NEC PC-8201A/8300; CFRJMK20.BAS for GW-BASIC/QBASIC, compiled as CFRJMK20.EXE for MS-DOS/Windows) How it Works: The Algorithm CFRJMK is a substitution cipher: it replaces each character in a readable "plaintext" file (or keyboard entered) with a random character in a (separate) unreadable "ciphertext" file. The translation from plaintext to ciphertext ("encryption") is accomplished by subtracting the ASCII value of each plaintext character from the "working key", a number that changes, ideally, in a random (unpredictable) manner from one plaintext character to the next. A random number is no less random after a non-random number is subtracted from it, making the ciphertext as random as the working key. The process is reversed ("decryption") by subtracting the ASCII value of the ciphertext character from the same working key value to recover the plaintext character. (If C = K - P, then P = K - C.) To make the working key sufficiently random to prevent cryptanalysis (decryption without the key being given), it is formed from the ASCII values of characters ("keytext") taken from several optional interactive sources, and the evolving working key is in turn used to make the random selections required. This interactivity should make effective mathematical modeling difficult if not impossible. The initial value of the working key is established by the weighted sum used to check the "passwords" entry. To encrypt each plaintext character, the working key (which is zeroed only when its size becomes excessive for an integer) is modified by the sum of any or all of the following, which are read (as a mutually interactive group) a random number of times: at least once, and up to a maximum number entered at the "security level" prompt: * The ASCII value of a character read from a "keyfile". Reading only one keyfile character for each plaintext character (and for each control code and shift tag), a truly random keyfile of sufficient length to be used only once produces a "one-time" cipher, the only cipher known to be not merely difficult or time-consuming to break, but mathematically impossible to break: the impossibility of solving one equation in two unknowns. Using a random number of keyfile characters for each plaintext character (security level > 1) makes it safer to use a coherent keyfile, such as ordinary English text, and makes keyfile reuse safer since the characters will be drawn in different groups at each reuse as long as different keytext from other sources (or "autokey") is used. CFRJMK has several features to facilitate the management of a keyfile used for true "one-time" encryption. A built-in generator can be used to produce a truly random keyfile using a flow of pseudo-random numbers interrupted and modified by the "human randomness" of key presses. The total number of keyfile characters read is displayed at the close of the program. (If the end of the keyfile is reached it will be automatically closed and reopened, also noted at the end.) If a large keyfile is used for encrypting multiple plaintext files, the total number of keyfile characters previously read can be entered at the "Skip..." prompt, so that only new characters will then be read. (The keyfile is closed and reopened after the initial fontstring permutations described below, with a new skip after reopening, so as to use the same characters as used during the encryption or decryption proper.) * The ASCII values of two characters selected from the "keystring", which is initially formed from a combination of keyboard-entered keytext ("passwords") and the program-resident keytext (or a substitute from a file), and is as long as the longest of the two; if keytext from only one of these is used, it is combined with itself. One character is selected in a methodical front-to-back sequence and is then replaced by a character formed from the working key after the randomly selected second character is read and its ASCII value added. Prior to encryption or decryption, the keystring is altered during the permutations of the "fontstring" described below. Since each permutation uses 95 cycles of the working key generator, three permutations (the default number) are required to completely reform the longest (255 character) keystring. (To reform the keystring twice requires six permutations, but to do it thrice only requires eight.) * The ASCII values of two randomly selected characters read from the "fontstring", which consists of one of each of the 95 printable 7-bit ASCII characters (32 through 126). By itself, the fontstring can provide the number needed to convert any plaintext character in the same range into any ciphertext character. The plaintext characters are all in this range during encryption since any outside this range is shifted into it, using only the equivalent of ASCII 32 to 122, which leaves space for each such shift to be preceded by one of three "shift tags", equivalent to ASCII 123, 124, or 125, which is encrypted along with the plaintext. (126 is not presently used.) Only one shift tag precedes a sequence of any length in the same range; another tag precedes a subsequent shift to either of the other two ranges. If any of the three bytes used as shift tags (or 126) appears in the plaintext it is downshifted below 123 in the same way as those above 126. The fontstring is continually permutated by being split and reassembled with the second selected character moved to the end of the string where it is protected from further similar selection until all the characters have been so relocated. The fontstring is thus completely reorganized after 95 encryptions. The option is given for any number of these complete (95 character) permutations to be performed prior to the actual encryption or decryption in order to "shuffle the deck": increasing the randomness of both fontstring and keystring. * The ASCII values of all the previous plaintext (summed modulo 95). This "autokey" provides a continuous supply of new keytext, albeit only as random as the plaintext. It makes the ciphertext "all one piece", difficult to analyze in sections except at the start (where the plaintext should have random characters for added protection). A disadvantage to using the autokey is that an error in the ciphertext (caused, e.g., by noise during transmission or corruption during storage) results in all of the subsequent deciphered plaintext being unreadable, rather than just the single corresponding plaintext character. Defeat the autokey if errors are anticipated. This will not isolate all errors: an error involving a shift tag or the deletion or addition of a character will still make the following plaintext unreadable. Using trial-and-error to change or delete the erroneous cipher character may then be the only recourse. * A number from the pseudo-random number generator. This should be used only if the same software is used for both encryption and decryption. If the operating systems or interpreters are different, the safest choice is not to use it. Each of these components may be selected (or de-selected) in order to provide the desired trade-off between security and speed or convenience, and also to permit their individual evaluation. These and the other options together with the keytext constitute the "key": all of the variable values added to the program for encryption that must be precisely reentered for decryption.