------------------------------------------------------------------------------ This is the first public release of OTP-PC, which is a MS-DOS implementation of the one-time pad or Vernam Cipher. The one-time pad is the only encryption method proven to be unbreakable. Complete source code is included. Please send comments, suggestions, and bug reports to: jpinson@fcdarwin.org.ec or jpinson@harpo.dev.uga.edu ------------------------------------------------------------------------------ Please read the read.me file, for additional information. OTP-PC features: -Automatic compression of plain text messages prior to encryption. Compression reduces consumption of the pad, and masks the size of the original document. (compression can be overridden) -Automatic wiping of the pad (codebook), to prevent reuse on both encryption and decryption. -Wiping and deletion of intermediate compressed files. -Two stage cipher text headers. The first stage header is un-encrypted, and contains information needed to start decryption. The second stage contains sensitive information, and is encrypted. -A 32 bit CRC stored in the encrypted header verifies reconstruction of the original file. -A verbose mode which displays encryption/decryption statistics. Note: A built in binary -> ASCII converter (Like UUencode or Base64 ) was not finished in time for this release, but will be included in version 1.1 version. It is the currently the hot season here in Galapagos, and I can't operate the computer much of the time. I will resume work by June, 1994. If there is interest, I will create a text-window (point and shoot style) version, and perhaps a Linux port. What is a One-Time pad? The one-time pad (OTP), or Vernam cipher, was created by Gilbert Vernam in 1918. The OTP is the only encryption system in the world that is considered to be unbreakable. The original one-time pad was so named because it utilized a note pad which contained sheets of paper filled with random numbers. Plain text was converted to numbers, and these numbers were "added" to the random number to create an encrypted message. Once the message was created, the sheet containing the random numbers was removed from the pad and destroyed (or eaten if you believe the movies). The encrypted message was then sent to the destination, where the process was reversed, using another copy of the random number pad to re-create the original message. The unbreakable nature of the pad comes from the fact that purely random numbers are used to encrypt the message, and no part of the random number sequence is reused. This is like having a huge un-guessable password as big as the text being encoded. There are no underlying algorithms or patterns to be discovered. Without a copy of the original random number sequence, it is impossible to reconstruct the message. All other forms of encryption (to my knowledge) use some algorithm. If you can figure out the technique used, you have a tool you can use to "crack" the code. Additionally, any method of encryption that employs a conventional "password" can be attacked by a "brute force" approach. For example, it is often possible to create a computer program that uses all possible passwords to decipher the encoded file. After trying a password, the program could automatically look for recognizable text within the deciphered file. If recognizable text is produced, then it is likely the correct password has been chosen. This approach does not work with the OTP cipher. First of all, the pad (password) is as big as the message, and it would take a VERY long time to try all the possible pads. Second, if you could try all possible Pads, you would end up producing *all* possible messages of the same length. There would be no way to guess which of the myriad of readable messages was the real one. The OTP has had quite an interesting history. Upon his death, Ch‚e Guevara found to have a OTP in his possession, which he used to communicate with Fidel Castro. The former Soviet Union is reported to have used the OTP for secure communications with it's foreign embassies. There are still reports that the OTP is still used by some countries for ultra secure communication. OTP-PC is designed along the same lines as the original, but with enhancements made possible by modern computers. The paper based "Pad" is replaced by a random binary file, the addition (a bitwise XOR) is done by the computer. OTP-PC XOR's the original message with the random pad file to produce an unrecognizable encrypted file. When the encrypted file is again XOR'ed with the pad file at the destination, the original text is reproduced. The distasteful "eating" of the pad is simulated by overwriting the pad, to destroy portions used during encryption. (This is a bit like the audio tape reel in the old "Mission: Impossible" show that would self-destruct after use) Precompression of the original message reduces the amount of pad consumed, and hides the size of the original message. OTP-PC is designed to give you the unbreakable protection of the original one-time pad cipher, in a modern easy-to-use package. ----------------------------------------------------------------- Is OTP-PC right for your encryption needs? Probably not. (you didn't expect that answer did you?) Although OTP-PC is unbreakable when used correctly, it (and all OTP's) suffer from one major problem. You must exchange copies of the pad with each person with whom you wish to communicate. The pads must be originally created and stored on a "secure" computer, the pads must be safely transported to the destination, and stored at the destination on a secure computer. Also, the pad(s) must be large enough to store all the messages you plan to transmit (at least until you can arrange another pad transport). These requirements make the pad unacceptable for many purposes. A corporation headquarters for example, may need to exchange many megabytes of information with its field offices each day. Securely transporting huge pads each day is not practical. It would be just as easy to send copies of the unencrypted data by armed guard. Other modern ciphers have no such size requirements, and allow unlimited amounts of information to be encoded. Additionally, "Public Key" ciphers allow individuals who have never met to exchange "keys" via E-mail and communicate in a secure manner. This is not feasible with the OTP. Still, in spite of these limitations, there are still situations where a OTP is useful. A situation almost tailor-made for an OTP is that of an embassy located in a foreign country. Messages of very sensitive nature must be sent every day, even though the communications links between the embassy and the home country are very likely to be closely monitored. In this situation, an OTP is a excellent choice. The pads can be brought into the embassy via diplomatic pouch, and safely stored in the communications room. The greatest threat to embassy communications comes from the possible decryption of transmitted messages, a feat that is impossible with a properly encrypted OTP message. In this situation, the transport and storage of the pads is not a major problem, and the OTP's greatest strength, its unbreakablilty, is of paramount importance. An added benefit for an embassy-type situation, is that the messages will remain unbreakable. New developments in math or number theory are unlike to allow the encrypted messages to ever be decrypted. Intercepted messages will still be unbreakable a 100 years from now. Another situation where a pad would be useful would be that in which a spy receives instructions via radio. The spy's location is unknown, so his pad is secure. The transmitter may be located in another country, so the pad on that end is secure. The only information the enemy has access to is the encrypted message, and if it is a OTP, it is unbreakable. Even for more mundane (and more realistic) situations the pad may still prove useful. In the case of the corporate headquarters we mentioned earlier, a conventional cipher could be used to send the bulk of the data, and the OTP reserved for the most secret, top level communications. An OTP could also be used to send long, secure passwords used for conventional ciphers. The corporation could send a small OTP encrypted file containing all the passwords used for the next month's communications. Also, it is possible to send an OTP encoded password, along with the conventionally encrypted message. At the other end, the OTP encoded password would be decoded, and then used to decode the conventionally encrypted message. (I am considering automating this feature in future releases of OTP-PC). So, the bottom line is that an OTP is not ideal for most uses, but is an excellent choice in certain situations. For many people, the main attraction of the OTP is its simplicity. You don't have to take chances with ciphers based on complicated math theory, that may have undiscovered weaknesses. The OTP is a proven, safe means of encrypting your messages. It has stood the test of time, and is generally accepted as the only unbreakable method of encryption. Using OTP-PC: A tutorial. The security features built into OTP-PC prevent you from doing "quickie" tests of the encryption features. Encrypting a message destroys the portion of the pad used for encryption, so you can't encode a message, then decode it to see if it works. I am not joking when I say "One-Time". The best way to fully understand the operation of OTP-PC is to simulate an actual message transfer. This allows you the chance to use all of OTP-PC's features. Please follow the step by step instructions below (or just read it to get a feel for the operation). ---Create directories---: First, create a directory for OTP-PC (for example: \otp ) and place the contents of the OTP-PC zip file there. Next, add this directory to your "path". (Example: "set path=c:\dos;c:\otp;") Create two new directories under \OTP, named jack and jill. These directories will simulate the computers of two people who will exchange messages. ---Create Pad files---: Now we must create two pad files. One will be used by Jack to send messages to Jill, the other will be used by Jill to send messages to Jack. Pad files have the extension ".pad". We will call the pad used to send messages to Jill "2jill.pad", and the pad used to send mail to Jack "2jack.pad" Jack and Jill must have *both* files. Jack needs "2jill.pad" to send messages to Jill, and he must also have "2jack.pad" to decode messages sent to him. Included in the OTP-PC zip file you will find two files containing random binary bytes. These files are named "one.rnd" and "two.rnd". We will use these files to create the two pad files we need. Change to your \otp directory, where you have placed the two *.rnd files. To create the pad file "2jack.pad" type the following command: otp -c one.rnd -o 2jack.pad That is the most complex command you will have to type. Encryption and decryption are *much* easier! OTP-PC uses standard UNIX style syntax. The -c option tells OTP-PC that we wish to "create" a pad file. "Options" are letters with the minus sign in front. (Unlike some UNIX programs, you can put the options at the end of the line as well as the front). (You may see a list of the options available by typing: otp -h) The first file name listed on the command line is "one.rnd", and is the name of the random file to use. The -o option specifies the output file to create, in this case it is "2jack.pad". The -o option must be followed by the output file name, but it doesn't matter if there are spaces between the "-o" and the filename. "-o 2jack.pad" and "-o2jack.pad"are both acceptable. You may also mix up the order of the commands: If you *really* wanted to, you could use any of the following commands, they all have the same meaning: otp one.rnd -c -o 2jack.pad otp one.rnd -o2jack.pad -c otp -o 2jack.pad -c one.rnd otp -co 2jack.pad one.rnd Remember: -o must be followed by the output filename. Note: OTP-PC has default settings. If you did not specify an output file name, the default would be to use the same name as the random file, but with a "pad" extension. The command "otp -c one.rnd" would create the default output file "one.pad". Also, OTP-PC will assume a default extension of ".rnd" for the random file, if one is not provided. Now repeat this process to create create the "2jill.pad" file. Type: otp -c two.rnd -o 2jill.pad ** Warning: Do not use the same random file to create both files ** The original random file is not altered, it simply provides data for the output file. The output file "2jill.pad" has a small header, followed by the random bytes, so it is slightly bigger than the original random file. ---Deliver the files to Jack and Jill--- Simulate the transport of the files to Jack and Jill by copying "2jack.pad" and "2jill.pad" into both the Jack and Jill directories. (Be careful, and make sure the files don't fall into enemy hands during transport :-) ---Play the role of Jack--- Change into the directory \otp\jack and create a message you wish to send. Save the message in the file "jill.txt". Now we can encrypt the file "jill.txt" using the file "2jill.pad". Remember to keep straight which file to use. Since you are now Jack, you will only use file "2jill.pad" to create messages for Jill. Type the following command to encrypt the file "jill.txt", using the pad file "2jill.pad" : otp jill.txt 2jill.pad That wasn't too hard. You could also use the command: otp -e jill.txt 2jill.pad The -e option specifies "encrypt", but OTP-PC is smart enough to figure you are doing an encryption when you list two file names, so the -e option is not really necessary. NOTE: OTP-PC will supply a default extension of "pad" if you don't specify a extension for the padfile name. While OTP-PC is encrypting the file, it prints a lot of information on the screen, the size of original file, the amount of space remaining in the pad and so forth. If you are not interested is seeing this "verbose" information, you may ask for "Quiet" using the -q option. otp -q jill.txt 2jill.pad By default, OTP-PC tries to compress the original file so your pad will last longer. If you don't want this feature, use the -n (no compression) option: otp -n jill.txt 2jill.pad When OTP-PC finishes, it will delete the temporary compressed file, and overwrite the portion of the pad used for encryption. You will see the encrypted file as "jill.otp" in the current directory. The final encrypted file has the same name as the original, but with an extension of ".otp" You may use the -o option to specify a different output file. otp jill.txt 2jill.pad -o newfile.out The command show above would create the output file "newfile.out" instead of the default file "jill.otp". OTP-PC has a built in safety feature to help prevent misuse of the pad files. The pad files are originally created in a "undefined" state, they can be used for either encryption or decryption. The first time you use a pad file to encrypt (or decrypt) a message, it is flagged so it can only be used for that purpose. Once you use a pad file to encrypt a file, it cannot be used for decryption. Since the portion of the pad used for encryption is overwritten, you wouldn't be able use it for decrypting the same message even if you tried. The flagging feature helps prevent such misuse. --Send the encoded message to Jill-- Copy the message "jill.otp" to the directory \otp\jill Note: If Jack mailed the binary file to Jill via e-mail, he would have to convert the message to text, using UUencode, BinHex, or some other binary->ASCII converter. Jill would then have to convert the file back to binary form. Some E-mail systems will do this automatically when you send files. Release 1.1 of OTP-PC will include a built in ASCII encoder. --Play the role of Jill-- Change directories (and perhaps your gender) into the directory \otp\jill --Decode the message---. This is the easiest step yet. Just type the following command: otp jill.otp If you like to be precise, you could also use the decode option: otp -d jill.otp Or even: otp jill This command is so easy to use because of the two stage header used in all files encrypted by OTP-PC. A small un-encrypted header in "jill.otp" contains the name of the pad file required for decryption (2jill.pad), and it also contains the offset with the pad file where decryption should begin. The first step OTP-PC takes after encryption begins is to decode the second part of the header, that contains more sensitive information that we would not want an enemy to know. Within the encrypted header is stored the CRC32 which we use to verify the reconstruction of the original file. Also stored in this header is the name of the original plain text file, which is being restored. Additionally, there is a flag to indicate whether the file was compressed before encryption, and which form of compression was used. The default verbose mode will tell you what is happening. When the process if finished, and the CRC32 is confirmed, you will be informed of the successful decoding of the message. The last step taken by OTP-PC is to overwrite the portion of the pad used for decryption, and the overwrite of any temporary compressed files. As an additional safety check, OTP-PC will only use a undefined (unused) pad, or a pad that has been used only for decryption. OTP-PC will refuse to use an encrypt-only pad to decode a message. Note: Since the "2jill.pad" file is overwritten during decryption, Jill cannot decode the message a second time. If she deletes (or wipes) the reconstructed file "jill.txt", there is no way to reconstruct the message. Although this can be a disadvantage if you make a mistake, it is also a useful security feature. That's pretty much it. You may complete the process by creating a new message as Jill, and encrypt it using the "2jack.pad" file and sending it Jack. At this point, Jill can't make a mistake and use the wrong pad file for encryption. The "2jill.pad" file has been marked "decrypt" only, so Jill is only able to use the "2jack.pad" file to encrypt messages to Jack. One extra command line option that you may find useful is "wipe-file". If you wish to wipe and delete a file such as "jill.txt" type : otp -w jill.txt The file will be overwritten and then deleted. Use with care, you can't recover a file deleted in this manner! There is also a "simple XOR" command, that will perform a bitwise XOR on two files to produce an output file. For example: otp -x fileone.txt filetwo.txt This will XOR the files "fileone.txt" with the file "filetwo.txt" to produce the default file "fileone.xor". You may specify a different output file with the -o option as described previously. The output file will have the same size as the smaller of the two input file. No overwriting of either source file is done, and no header is preappended to the output. We will see how this feature can be used to create "random" data files in Appendix B. Is OTP-PC really Unbreakable? To the best of my knowledge the cipher text (encrypted file) produced by OTP-PC is totally unbreakable if the following conditions are met: 1) A cryptographically "Random" file is used to produce the pad file. 2) The pad files are stored on a "secure" computer. 3) The pad files are transported in a secure manner and are not intercepted during transport. Condition 1 is a bit difficult to meet, and we will discuss that at length in Appendix A. Condition two is important with any form of encryption, and is not limited to OTP-PC. It is pointless to encrypt messages, if you leave the original plaintext message on a publicly accessible computer. A computer on a network, or in an office, is particularly vulnerable. Even the "power-up" password gives only limited protection. If someone really wanted your data, the hard drive could be removed from your computer and temporarily placed in another computer so the data could be read. If properly done, you would not ever know your data had been compromised. And speaking as a network administrator (mostly Novell), I can say with certainly that if you are on a computer network, you have no guarantee of privacy. There are numerous network management tools that allow administrators to "update" user's hard-drives and even see what you are typing on your keyboard. These tools all have legitimate uses, but the potential for misuse is always there. Assume nothing is save from prying eyes on your computer's hard drive, or network directory, if you are attached to a network. Electromagnetic radiation from your monitor can be picked up by special equipment which would allow an enemy to see what is displayed on your screen (the Tempest attack). For most purposes however, keeping your sensitive data on you home computer, and using one of the software disk encryptors or partition scramblers (products like Diskreet or DiskLock) should offer reasonable protection. There are also some shareware disk encryptors such as SecureDrive that may be useful as well. If you have an enemy that is Omniscient or Omnipotent you are plain out of luck. OTP-PC has no foolproof mechanism to protect your data if some one gains access to your computer. Even the pad overwrite feature is of little use if you keep the plain text around. OTP-PC is designed to protect encrypted data from being read during transport. Before it is encrypted, or after it reaches it's destination, it is up to the user to protect it. Condition Three, secure transport of pads, is a bit of a problem. You shouldn't just mail the pad files. If you use a courier, they must be careful not to leave the diskette lying around a hotel room while they go out to lunch. There is of course, another consideration regarding the security of OTP-PC. Even if the standard OTP is unbreakable, OTP-PC is a modified version, and it is possible that weaknesses have crept into the design. I have been very concerned with this problem. I wanted to make OTP-PC easy to use, and automate the decryption process. Yet, I did not want to compromise the security. This has been a difficult problem. The unencrypted header used in the cipher text file (*.otp files), has information needed to start the decryption of the file. Does this compromise the security? I think not, at least not any any significant way. The cipher file contains the following information in the unencrypted header: Signature: A text string showing the file is a OTP cipher file. Version: The version of OTP used. Padfile name: The name of the pad used to encrypt the message. bookmark: The starting place in the pad where decryption should begin. Start: Where to begin decryption in the Ciphertext file. It might be argued that any information accessible the enemy is dangerous, but let's consider what we have really revealed. The enemy will know it is a cipher file, and the version of the software known. However, that does not help the enemy decipher the message. The strength of a OPT comes from the encryption technique, not from hiding the fact it is a OPT. The enemy will know the name of the pad file used, and the staring place within the pad file. That information is of no practical use because we are assuming the pads are stored on secure computers. If the enemy has access to your padfiles , you are are out of luck anyway. You can also use meaningless names for your pad files if you wish greater security. For example, instead of calling the file "2jill.pad", you could call it "afe3z8cu.pad". Therefore, in my humble opinion, nothing of any value is revealed in the unencrypted header. The benefits gained from using a header, specifically the nearly automated decryption, make up for any information given the enemy. Following the un-encrypted header is the encrypted header, which is encrypted using the same technique as the rest of the data. The encrypted header contains the following information: -CRC32 of the original plain text. -Name of the original plain text file. -Compression flag to indicate if compression was used (it also indicates which technique was used). -An Integer (currently unused, reserved for future use). These bits of information, if revealed to the enemy, could indeed be of practical use. Take for example the CRC32. The CRC32 allows us to verify the successful reconstruction of the original file. The enemy could also use it for the same purpose. We stated earlier that the OTP was immune to a brute force attack. If an enemy were able create every possible random pad file, and use it to decrypt the ciphertext, they would end up creating every possible plaintext message of the same size. They would have no idea which message was the real one. If the enemy had access to the CRC32 of the original file, they could use that information to narrow the possibilities. Decrypted messages that didn't have the same CRC32 could be discarded, and the matching ones kept. There would still be a LOT of possible messages with matching CRC32's but far fewer than you would have otherwise. Since the CRC32 is encrypted along with the main message, the original immunity to brute attack is restored. Decoding the ciphertext with all possible pads would produce all possible message *with* their matching CRC32. (Actually, it would also produce all possible messages with non matching CRC32's as well). To further complicate the matter, an enemy would have no way of knowing if the message had been compressed prior to compression or not. This means the enemy could not even ascertain the length of plain text message being sent. This means that if you are sending a large password via OTP-PC, the enemy will be unable to even guess its length. We also hide the compression flag, so the enemy can't know if (or what) compression was used. The name of the original file is also hidden, least it reveal anything about the contents. If you feel that the use of headers is risky, you can still use OTP-PC. Use the XOR function to XOR bytes of your message directly with a random number file. In our example, jack could use this command to create a file for Jill. opt -x jill.txt one.rnd Jack would then send the file jill.xor (the default output file), to Jill, who would then reverse the process with the command: otp -x jill.xor one.rnd I you use this direct approach, you would have to be very careful never to use the same random file twice, and would have to know which random number file to use to decode messages. This method is a bit clumsy, but does remove any question about the use of headers. Notes on file wiping: Many programs wipe a file by overwriting each byte of the file with a single character. Sometimes the programs will make several passes over the file using a different character each time to help insure erasure. Some concern has been expressed about using this technique on files stored on compressed disks, such as Stacker or DoubleSpace. The fear is that the repeated characters will be compressed and the overwritten bytes will take up less space than the original bytes, perhaps leaving unwiped space at the end of the file. OTP-PC uses random bytes to overwrite files and is not likely to miss any part of the file. APPENDIX A Creating Random Numbers. Random numbers are the heart of OTP-PC. The use of a non random pad file, or the reuse of any pad defeats the unbreakable nature of the OTP. Random numbers, at least in a cryptographic sense, are numbers whose sequence are unguessable by an enemy. The enemy must be totally unable to guess any part of the sequence. Knowledge of part of the sequence should not provide any information useful for ascertaining the rest of the sequence. There are several techniques that may be used for the creation of random numbers, some of which are much better suited to the task than others. Random numbers are used for many different purposes. Scientists use random numbers, often from tables found in statistics books, to assign treatments to test subjects. Game designers use software based random number generators to better approximate real word events, such as the actions of computer-generated opponents. The techniques used for creating random numbers for many of these purposes are not adequate for cryptographic purposes. Looking up random numbers in a table may be acceptable for a scientist, but using such a table as the basis for a OTP is most unwise. An enemy could also have access to the same tables and potentially could then decode your messages. Software based random number generators, or Pseudo Random Number Generators (PRNG), are generally not a good choice either. Most PRNG's eventually start repeating themselves, and any pad created from such numbers would also have repeating number sequences. As you remember, a pad should *never* be reused. Most PRNG's require a seed number, which may be generated automatically by the software, or may be supplied by the user. Different seed numbers create different different sequences of random numbers. If a PRNG uses an 8 bit seed number for example, that would mean that there could only be 256 possible random number sequences! An enemy would only have to try 256 combinations to find the one you are using. So, table based random numbers are not acceptable, and neither are most PRNG's. What does that leave us with? If you are a high tech type, you could hook up a Geiger counter to your computer, and measure decay intervals from a radioactive source! Radioactive decay intervals are considered to be truly random. Others have suggested recording the output from open microphone port, on a SUN Workstation, or perhaps a SoundBlaster card on a PC to get random "hiss", and then compress the sound file to remove redundancy. All these options are workable, but you have to be sure what you are doing. The source, such as that from a sound port, may not be as random as you think. Also, you would have to be careful doing any processing of random numbers, least you accidentally add non random features to the output. Other ideas, such as memory resident programs that record tiny variations in time between keypressses may also provide a good source for random numbers. However keep in mind that any such program should under go serious scrutiny before you should trust them. (Just because someone claims their progam generates random numbers does not make it so). Is there a simple method, that the average person can use to crate random numbers? On possibility, which may have already occurred to you is to use an existing program or data file contained on your computer as a source of "random" numbers. Certainly the enemy could not know what file you used, and therefore could not guess the sequence. Unfortunately, this is not a good approach. First of all some program and data files have repeating sequences of numbers. A large sequence of repeating numbers would not properly encode your message. Many program files or data files have certain fixed information, such as headers, that would increase the vulnerability. Another danger is using an existing file that is easily accessible to the enemy. Using MS-DOS command.com file as your source of random numbers would be very unwise. In spite of all this, I believe it is quite possible to safely use existing data files for creating random numbers. The technique is to use two or more data files that you are sure no one else has access to, and XOR these files together. The XOR function is quite good at scrambling information, after all, it is the core of the OTP process. Any pattern pattern existing in any single file is removed. It is very important to use data files of different types when you do this. If you XOR a data file that had a fixed header, say a PKZIP file, with another PKZIP file, you would end up with a predictable result where the headers overlap. You should also use data files with a lot of variability. If you decide to use a PCX picture file for example, use one that is "busy", not a picture of a white cow in a snowstorm. (some picture formats compress the picture, which might make the white cow more acceptable) A example of a good combination of files to use might be to take a digitized picture of your child's birthday party (a photo you did not share with anyone), and XOR it with WAV sound file recorded at the last New Year's Eve celebration (one you are too embarrassed to share!). You would do the XOR with the command: otp -x child.pcx party.wav The output file "child.xor" should be quite unpredictable, and therefore "random" in the cryptographic sense. You could XOR the output file with yet another file if you wanted to be extra cautious. If you XOR with a third file, chose one other than a .pcx or .wav file to avoid repeating headers. I cannot see any way an enemy could possibly guess the random number sequence of the resultant file. The enemy could not know which files you used, or how many XOR steps you preformed. Even if he knew all this, he would not have access to the files. No one has them but you! He could not even know if you used this technique at all or not. In any case, the final responsibility of generating random numbers is yours. OTP does not come with a random number generator, or any "officially" recommended method of producing random numbers. If you have a Geiger counter handy, or some other method of generating numbers you trust, by all means use them. Otherwise, consider my thoughts on XOR'ing files. If my suggestion sounds reasonable to you, give it a try. Jim Pinson Galapagos Islands, Ecuador. jpinson@fcdarwin.org.ec jpinson@harpo.dev.uga.edu