CFR2DG.DO by James Main Kenney Supplementary documentation for the "true-random" keytext generator built into CFRJMK 2.0 (CFRT20.BA, CFRN20.BA, CFRJMK20.BAS/.EXE). The built-in keytext generator can be used to create a keyfile (main, or replacement resident) or to append characters to an existing keyfile. It can also be used to append characters to the CFRJMK source code (CFRT20.DO, CFRN20.DO, CFRJMK20.BAS) in order to change the resident keytext (see CFR2D4.DO). The most challenging application is to create a (main) keyfile sufficiently random for "one-time" encryption in order for the ciphertext to be unbreakable (in practice, if not in theory). The BASIC source code for the generator is on lines 46, 47, and 48 of all versions of CFRJMK 2.0. This generator was adapted from the author's RNDMGN.BA and RANDMGEN.BAS/.EXE, simplifying them by using a fixed character range (ASCII 32 - 126) best suited to CFRJMK, and eliminating the optional input file. These generators use a source of true randomness external to the completely deterministic computer, but do not require special hardware (using thermal and shot noise, e.g.) commercially unavailable at present. This source is the "human randomness" of key presses (actually using very complex "hardware", but readily available at no cost!). Two types of "human randomness" are involved: in the choice of which key to press, and in the choice of when to press it. Because of human limitations, neither of these can be perfectly random, particularly in the choice of keys, but together they can provide sufficient randomness to destroy the underlying mathematical relationship between the numbers produced by the operating system's pseudo-random generator, which provides the good distribution of numbers that the choice of keys alone cannot. A keyfile can be produced (or added to) during the initial prompts of an encryption (as described in CFR2D4.DO), but it can also be produced prior to encryption using the following steps: 1. Run CFRJMK and press key E at the first prompt, then press only ENTER at the next two prompts. 2. At the prompt "Keyfile?", enter a filename, then again press only ENTER at the next two prompts. 3. At the prompt "Add 0 random chrs?" (Kyocera versions) or "Add 0 random characters to keyfile?" (IBM version), enter a number for the keyfile size. For one-time encryption, it must be as large as the ciphertext file, which is usually slightly larger than the plaintext file. For testing, create a very large keyfile. 4. "Tap keys randomly, (ESC) ends" will then appear; press any key to start a continuous flow of characters formed from pseudo-random numbers. These characters are only printed to the screen, and not otherwise used except that the numbers are summed modulo 95. 5. Tap a key at any time and observe the appearance of a character (generally different from the key selected) in reverse video, embedded in the normal-video characters. This character is generated in the printable 7-bit ASCII range (32 - 126) using, in part, the same pseudo-random process, but the ASCII value of the struck key is added, and the character is appended to the keyfile. It is accompanied (also in reverse video) by a count of the filed characters. (To read on a fast computer, pause the computer immediately after striking a key; this can usually be done by holding down key FN while striking first any key then PAUSE.) The flow of (discarded) pseudo-random characters then continues until the next key is struck. The pseudo-random generator output is thus sampled at random intervals, destroying the mathematical relationship between the numbers. Coherence is further destroyed, and the numbers rendered irrecoverable, by adding the ASCII values of the struck keys (and the modulo 95 sum of the previous key values, plus the modulo 95 sum of both used and discarded numbers). The pseudo-random generator provides a good distribution, converting numbers from a highly-biased selection of keys (e.g., all capital letters) into well-distributed numbers. Adding the previous values further aids distribution by providing a variable starting point. The weakness of each number source is thus concealed by the strength of the others. Randomness destroys coherence (this is the basis of modern encryption), but the converse is not true. (Entropy always increases.) 6. Tap randomly selected keys at irregular intervals, using the SHIFT key to widen the range. Since the ASCII values are added modulo 95 (and 32 then added), high 8-bit characters and control code are equivalent to printable 7-bit characters (ASCII 32 -126), but can be used for diversity. Tap letters, numbers, punctuation marks, the space bar, and even ENTER and TAB, but not ESC, which exits the generator (or CTRL-C which may exit the program!). Watching the screen may or may not help in achieving random intervals: it can reveal unconscious rhythms, but can also introduce bias. Although tedious, long intervals between keystrokes are best. An analogy is blindly stopping a rapidly rotating wheel at erratic intervals. If the stopping positions on the wheel were numbered in numeric order, the stops could generate a random sequence, but they must be infrequent (allowing multiple repetitions of the sequence) for a good distribution. Using pseudo-random numbers improves the distribution if the stops are frequent. The wheel size is then analogous to the repetition period of the pseudo-random generator, which is very large, rather than having only 95 positions. Patience is required for best results. For one-time encryption, think of preparing the keyfile as typing a rough manuscript (very rough!) about the same size as the material to be encrypted. This is obviously a method best suited for the one-time encryption of short and infrequent messages, or to prepare shorter keys for less secure encryption. (Note that a random long key can be encrypted using a shorter key, with no danger of discovery by a brute-force attack since there is no way for a successful decryption to be recognized as such. If its nature is suspected, however, then all outcomes could be saved for attacking a later encryption, although this would be no worse than if the short key had been used directly.) 7. Exit from the generator will be automatic when the entered keyfile size is reached; press ESC to exit earlier. 8. Enter a dummy name at the cipherfile prompt and exit CFRJMK by pressing ESC at the next prompt (then only ENTER, using CFRJMK20.BAS/.EXE). To analyze the results, run CHRCNT.BA or CHRCOUNT.EXE and enter the name of the keyfile, then enter the number of characters to be analyzed. A decimal multiple of 95 (less than the keyfile size) will produce counts that average an integer power of 10 for each of the 95 characters generated by CFRJMK; e.g., analyzing 9500 characters will produce an average of 100 counts for each character, making the deviations easy to note (and directly readable in percent). After an automatic exit to Menu or DOS (etc.), read COUNTS.DO or COUNTED.CHR to observe the character counts. How uniform are they? Do the number of characters with counts above average match the number with counts below? Read the keyfile and search for duplicate strings and other evidence of non-randomness. Using only the keyfile (rejecting resident keytext, passwords, autokey, pseudo-random generator, and fontstring), encrypt a large file (but smaller than the keyfile) and use the tests built into CFRJMK while encrypting (see CFR2D3.DO).