Gathering Entropy
To "salt" files for encryption and to suggest passwords, fpwdman requires an unpredictable stream of numbers. The more random, the better: higher entropy is better. For this, a psuedo-random number generator (PRNG) is provided. PRNG's require either an ongoing source of random numbers, or a large random block of data, in order to generate an unpredictable stream of numbers. It is possible to extract random numbers from such things as timing of disk access, timing of keystrokes, and so on. Unfortunately, there is no easy (for you, the user) and portable way to extract entropy from system operations on both Unix and Windows. Therefore, fpwdman offers a simple way to gather random data from the user, and restart the PRNG using that.
The Tools --> Gather Entropy command (or Alt-T, Alt-G) launches an entropy gathering dialog. By moving the mouse around inside the white square on the right side of the dialog, you can draw a random dot pattern. The dot-pattern is rearranged into a long bit string, which is used to seed the PRNG.
The maximum usable amount of entropy to gather is controlled from the preferences dialog. The particular PRNG in fpwdman only holds 3200 bits of entropy, so anything above that is just insurance. The maximum possible amount is dictated by the number of pixels in the white entropy-gathering window.
If your "PRNG Control" preferences are set to use "System Seed", then fpwdman will use the system's random number seed by default. It will not initiate the entropy-gathering dialog. Using only the system's random number seed provides very little entropy (32 bits at most), so this mode is discouraged unless you intend only to read the file, and not to modify it.
If your "PRNG Control" preferences are set to use "User Entropy", then fpwdman will initiate entropy gathering when the PRNG runs low. You can control whether it does this just once, or whether it repeats when necessary with the "Repeat" check button.
If you invoke the entropy-gathering dialog, fpwdman will use the entropy you provide, regardless of whether you set your Preferences to use the system seed or to gather user entropy,
For the technically minded:
- To SBC encrypt a file, fpwdman uses 160 bits of entropy to generate random "salt" at the start of the file. This is a standard cryptological trick which prevents identical password files from encrypting to the same ciphertext each time. fpwdman suggests passwords that only use printable ASCII characters (in fact, the standard Radix 64 set), so a 16-char password takes between 96 and 160 bits of entropy (depending on how neatly the char pack into 32 bit words). Hence, the 3200 bit PRNG can safely be used to encrypt password files 20 times, or to suggest 20 to 33 passwords, before gathering more entropy is advisable for even the most cautious user.
- Entropy is not carried over from session to session. To do so would require storing a file of random data on the disk - which could be altered and rendered non-random by an attacker. Even if it were encrypted with a secret password hard coded inside fpwdman, anyone with access to the source code (i.e. the whole world) could decrypt the file and manipulate it.
- If we have a drawing area with N pixels, and M out of N are marked, then there are K = N!/( M! * (N-M)!) ways to place those M marked dots in the area. Thus, a particular configuration of M marked dots has lg2(K) bits of information. This is the amount which fpwdman displays for the Current level of entropy. The particular formula used in the code is an algebraic simplification of the formula given above, but it computes the same number.
- To generate (say) 6400 bits of entropy, the bit-string of the drawing area is used as a very large secret key to SBC encrypt a fixed block of 6400 bits. Because encryption is reversible, it is one-to-one, so the entropy of the key is reflected in the entropy of output block - with which the PRNG is restarted.Even with all 0's as the key and all 0's as the input data, SBC returns a non-zero cipher block. As with any well-designed cipher, flipping any bit of the key or input has a 50/50 chance of flipping each bit of the output.
- That the output block does fully reflect the randomness of the key is not as obvious as one might think. The proof hinges on counting the number of different ways to map 6400 bits of plaintext into 6400 bits of cipher text (i.e., (2^^6400)! ), the number of different keys possible (i.e., 2^^21605 ), and the fact that such a sparse sampling of keys from the space is vanishingly unlikely to yield to different keys which map the same input block to the same output block.
