OTP 1.0 build: 9639 released: compiled with: Java 1.8.0_131 Jet jet12.0-pro-x86/1.8.0_131 One Time Pad. Copyright: (c) 2012-2017 Canadian Mind Products. Java application. Not distributed. ---- Notes: You must install the Java JRE to use this program. See http://mindprod.com/jgloss/jgloss/jre.html This program can only be used from the command prompt, (or via an command line style icon shortcut) e.g. under Windows command.exe or JPSoft tcmd.exe, formerly called the DOS box. Just clicking the programs in a directory listing will not do anything useful. Just typing the program names at the command prompt will not either. This program requires a manual install! See below. This program works with vanilla text files, (e.g. ASCII files or UTF-8 Unicode files). You will need a text editor to create and view them, not a word processor. e.g. notepad, Visual Slick Edit or other suitable text editor http://mindprod.com/jgloss/editor.html. You must use a monospaced font http://mindprod.com/jgloss/monospacedfonts.html (aka fixed pitch, aka programmer font) to view your files, or they won't look properly aligned. I put out an avalanche of free software into the world, and submit PAD files to hundreds of distribution sites, but I rarely hear back from anyone. What's happening? Does it all just work fine? It is so complicated nobody can figure out how to use it and they give up on it? It is it useful? Since everyone has the source, do people just fix the programs to their liking themselves? Did you have trouble installing? Do I presume you know too much? I would be happy to hear from you about your experiences, positive or negative and your requests for improvements. A one-line email to roedy@mindprod.com would be great. ===> Free <=== Full source included. You may even include the source code, modified or unmodified in free/commercial open source/proprietary programs that you write and distribute. May be used freely for any purpose but military. For more details on this restriction, see http://mindprod.com/contact/nonmil.html If you include any Canadian Mind Products code in your own applications, your app too must be labelled non-military use only. http://mindprod.com/contact/nonmil.html All Java jars and source code are included. If you need the class files or Javadoc, you will have to build them yourself. To streamline the zip downloads, class files and Javadoc have been removed. ---- Prerequisites: This program runs under any OS that supports Java, (e.g.W2K/XP/W2003/Vista/W2008/W7-32/W7-64/W8-32/W8-64/Linux/LinuxARM/LinuxX86 /LinuxX64/Ubuntu/Solaris/SolarisSPARC/SolarisSPARC64/SolarisX86/SolarisX64/OSX/AIX...) so long as you have <><> Java version 1.8 <><> or later installed (32-bit or 64-bit Java). See http://mindprod.com/jgloss/installingjava.html for details. ---- Installing on a PC: Download source and compiled jar files to run on your own machine as an application. First install a recent Java JDK or JVM. See http://mindprod.com/jgloss/installingjava.html. To install, extract the zip download with WinZip (or similar unzip utility) into any directory you please, often J:\ -- ticking off the use folder names option. To run as an application, type: java.exe %JAVA_OPTIONS -ea -jar J:\com\mindprod\otp\otp.jar {put any parms here} adjusting as necessary to account for where the jar file is. ---- Installing on a MacIntosh: Use Safari to download source and compiled jar files to run on your own machine as an application. Safari will automatically unpack the zip into ~/Downloads (version 10.5) [or on the Desktop (version 10.4 and earlier)]. First install a recent Java JDK or JVM. See http://mindprod.com/jgloss/installingjava.html. You may optionally move the download tree to a permanent home. I don't have a MacIntosh, just a PC, so I can't test my Java programs for Mac compatibility. In theory they should work without problems, but in practice that does not always happen. If you have problems please, let me know, preferably with screenshots and complete verbatim error messages. To run as an application, without parameters, just double click the jar file. To run as an application with parameters, in bash shell type: open Terminal.app cd ~/Desktop java.exe -ea -jar com/mindprod/otp/otp.jar {put any parms here} adjusting as necessary to account for where the jar file is. ---- Rebuilding: The zip already contains the necessary jar files, so unless you modify the program, there is no need to recompile the source or rebuild the jar. Configure.java basedir="E:/" in rebuild.xml to the drive where your files are. Use ANT and rebuild.xml, not build.xml, to recompile and recreate the jar. ---- Use: Encrypt/Decrypt use a one time pad of true random numbers. In theory this is encryption is uncrackable. In practice a snoop can break into either sender or receiver computers and look at the plain text or steal a copy of the PADs of random number. Or they might intercept the courier delivering pad to the receiver and make a copy. However, they can do absolutely nothing with an intercepted encrypted message if they don't have the corresponding one-time-pad. You must somehow generate a set of pad files named *.pad in the current directory. See http://mindprod.com/jgloss/truerandom.html for various techniques. You want to run some statistic tests on your sources to make sure they are behaving correctly, and no one has access to your generator to corrupt it in some way. When you run Encrypt, you select the file you want to send. It automatically selects one of your pads, or part of a pad, and xors with the file you want to send creating a xxxx.enc file you send to the recipient over an insecure channel such as email. Encrypt wipes the pad, or part of the pad. It does not wipe the original plaintext file. When you run Decrypt, you select the encrypted file you want to reveal. Decrypt automatically select the corresponding pad or part of a pad and xors with the encrypted file creating the xxxx.doc or whatever the original file was called, in the the same directory as the encrypted file. It then wipes the pad, or part of the pad, and the encrypted file. The encrypted file looks like a stream of random binary bytes, (not armoured). You can send it as an attachment, but not in the message body unless you armoured it with Base64 or something similar. See http://mindprod.com/jgloss/armour.html USE 1. generate a some random pads, or one big random pad. You must use truly random, not pseudorandom pads, for the code to be uncrackable. Everything will still work, but with lower security if you generated the pads with pseudorandom generators. See http://mindprod.com/jgloss/pseudorandom.html. To be safe, assume every message you send will consume about n + 200 bytes bytes where n is the length of the original file. It won’t to have more pads than you strictly need. These pads are best kept on a password protected, AES encrypted USB Flash Drive such as a Kanguru Basic. If you leave them lying around on hard disk they are vulnerable to the usual OS attacks. If you put them on CD, Encrypt could not wipe them after use. 2. You must get copies of all the pads ahead of time to your recipient without them being intercepted. Ideally the recipient comes to visit the sender ahead of time, and takes the pads away on password protected, AES encrypted USB Flash Drive such as a Kanguru Basic. He must carefully guard them from even momentary glipsing on his trip home and store them securely. You might send them burned on a CD by mail, but snoops might intercept you parcel and make a copy of the CD. You might send them by courier, but then your courier might be bribed or threatened into handing over a copy. I suggest putting them on a password protected, encrypted USB Flash Drive such as a Kanguru Basic. If it is intercepted there is no way to retrieve the keys without the pass phrase. You still need some way of securely getting the password to the recipient. You could do that with The Transporter. http://mindprod.com/products.html#TRANSPORTER. This is very high, but not uncrackable incryption. If someone cracks that they still need access to your USB to enter the passphrase. Your phone could be tapped. Your mail could be opened. Since the scheme cannot be attacked directly, you must defend yourself against various indirect attacks. 3. Sender runs encrypt. e.g. encrypt.jar It will potentially use any pad or part of a pad in the current directory. You don't want pads in there that the receiver does not yet have. 4. Email the encrypted file to the recipient. 5. The receiver runs decrypt, e.g. decrypt.jar Decrypt will expect to find a copy of the pad used to encrypt the file in the current directory. If it is not there will not be able to decrypt the file. The receiver may decrypt the files in any order. Decrypt will hang on to pads until all corresponding messages are decrypted then it will delete them. 6. If you start running out of pads, you have to make some more and get them securely to the receiver well in advance of needing them for decryption. 7. If ever you suspect some party has seen any of your pads, you must delete them all and start over with newly generated ones. You might want to prepare for that eventuality with a second independent set of pads sent in advance and stored separately offsite. 8. Let us say you send 5 years worth of pads to the recipient. That gives third parties 60 times as long to steal a copy of them than if you send only a month's worth in advance. SIMULATION If you want to simulate sending and receiving on a single computer you will need two directories: sender\clear : plain text messages (can come from anywhere) sender\encrypted : messages after encryption sender\keys : pads (files of random numbers named xxx.pad) receiver\clear : decrypted plain text messages receiver\encrypted : encrypted messages prior to decryption (can come from anywhere) receiver\keys : copy of pads send ahead of time When you run encrypt, the current directory must be the sender directory (which can be named anything you want, even the root). When you run decrypt the current directory must be the receiver directory (which can be named anything you want, even the root). You may not share the same directory for receiver and sender pads because encrypt wipes pads immediately after encryption. You need a second unwiped copy to decrypt. Create some pads in the sender\keys directory. You can fake some by renaming some zip files to *.pad. You could use makekey or other techniques to create some true random pads. Copy them to the receiver\keys directory before you do any encryption! Then run encrypt in the sender directory. The encrypted file will appear in the sender\encrypted directory. Copy it to the receiver/encrypted directory. Then run decrypt with receiver as the current directory. The decrypted result will appear in the receiver\clear directory. Encrypt wipes the oringinal plain text file, and Decrypt wipes the encrypted file. If you want to do comparisons you will need extra copies. FORMAT OF ENCRYPTED FILE The file name has the form enc1364566372716096346.encrypted. 16 bit int big endian : length in bytes of the pad file name (without directory), unencrypted n bytes Unicode-16 : name of the pad file name (without directory), unencrypted 64 bit 8-byte big endian : offset into pad to start. From here on everything is xor encrypted 16 bit int big endian : length in bytes of the original file name (without directory), unencrypted n bytes Unicode-16 : name of the original file name (without directory), unencrypted 16 bit int big endian : length in bytes of length disguiser ( 0 .. 99 ) n bytes of 0s : used to disguise the length of the original message. n bytes : contents of the original file. 32-bit 4-byte Adlerian checksum of the entire file including the unencryted header. Used to make sure the decryption was done with the correct and untampered pad and the the encrypted pad was not tampered with. Computed on the entire file prior to encryption. You don't need to understand the message format to use the program. CRACKING One time pads are in theory uncrackable. All that means is a third party wanting to intercept your communications will not attack by trying to decode intercepted messages. There are three other likely places they can attack: 1. snooping on or interfering with the sender's files, including looking at the file before it has been encrypted. 2. snooping on or interfering with the receiver's files including looking at the file after it has been decrypted. 3. snooping on or interfering with the pads being transported to the receiver. This is pretty easy if they are ordinary CDs, hard drives, or unencrypted USB drives. A third party may tamper with the sender/receivers programs, the pads, (adding new ones, modifying existing ones, deleting some), the plaintext file before or after encrypts. Ecrypt does a check to see if any new pads have appeared, changed length, or disappeared and reports to the user. Sometimes this is legit, sometimes not. A third party might make a copy of the pads when the courier is not looking. The easiest way to defeat most attacks is to keep the pads, programs and plain text files inside as password protected, AES encrypted USB flash drive at all times. They cannot be snooped on or modified. Further they can be removed from the computer and put in a safe where they cannot be stolen or disassembled. A keystroke logger hidden in the keyboard, or implemented with software or that works by RFI leakage could snoop as the password was keyed. Kanguru fights that by optionally using a virtual keyboard. A sophisticated attack could run as a background task, and pounce only when the user opened the flash drive giving the password. I have have not yet come up with a defence to this other than physical security, and disconnecting sender and receiver computer from the Internet. I have a request into Kanguru, a drive maker for a solution, one that would let only one program see the opened drive. PASSWORD EXCHANGE If a courier who does not know the password delivers a USB flash drive to the receiver, how does the receiver know the password to get at the files inside? 1. He might meet face to face to pick up the USB and learn the password. This is obviously the best approach. 2. It might be sent sealed in some way so that snooping could be detected. 3. Parts of the password might be mailed separately from letters posted in widely separated boxes. 4. It might be sent over the phone, hinting at shared secrets, without stating them explicitly. 5. In a visit, a set of passwords could be decided, for use in future, referring to them just by number 1 .. n. ZIP CONTENTS The source *.java is there. There it includes complete source for each package even when only some of the classes are used. There are complied *.class files. There are jars otp.jar wipe.jar encryt.jar and decrypt.jar. otp.jar is just a dummy. The OTP.java files contains configuring constants and common code. The *.png file are images you can use in documentation. The *.ico files are ico files you can assign to shorcuts you set up to lanunch the three jars, or assign as the official icons for the various file types, e.g. *.pad, and *.enc. The javadoc gives a stylised documentation for the programs, useful for getting an overview how they work. KANGURU Here are some of the things you can do with a Kanguru Basic Defender AES-encrypted drive. Transport private keys in it. Keep all you sen/receive pads in it, even when the Encrypt/Decrypt program is running. Keep all your confidential plaintext files in it. Keep you encryption/decrytion software in it to discourage tampering. Keep it in a safe when not being used. WORK TO COMPLETE 1. make sure you don't have two copies of encrypt or decrypt running at once. 2. inform of many errors with dialogs instead of console messages. ---- Version History: 1.0 2012-12-21 initial release. -30-