OneTime — Encryption with One-Time Pads
Update (2016-05-27): OneTime 2.0 is currently in beta testing. The latest version is 2.0-beta6 — please give it a try and report any bugs you find. See the compatibility notes for details about what's new in 2.0.
OneTime is an open source encryption program that uses the one-time pad algorithm to allow two parties to communicate privately. It has features to assist with the bureaucracy of pad management, and comes with built-in help. OneTime requires Python 2.6 or higher, and is for users who are comfortable running command-line programs. (It is not yet compatible with Python 3; there's an open ticket for that, and patches are very welcome.)
This is the output of 'onetime --intro':
OneTime: an open source encryption program that uses the one-time pad method. (Run 'onetime --help' for usage information.) The usual public-key encryption programs, such as GnuPG, are probably secure for everyday purposes, but their implementations are too complex for all but the most knowledgeable programmers to vet, and in some cases there may be vulnerable steps in the supply chain between their authors and the end user. When bootstrapping trust, it helps to start with something you can trust by inspection. Hence this script, OneTime, a simple program that encrypts plaintexts against one-time pads. If you don't know what one-time pads are, this program may not be right for you. If you do know what they are and how to use them, this program can make using them more convenient. OneTime handles some of the pad-management bureaucracy for you. It avoids re-using pad data -- except when decrypting the same message twice -- by maintaining records of pad usage in ~/.onetime/pad-records. (The pads themselves are not typically stored there, just records about pad usage.) Recommended practice: if you are Alice communicating with Bob, then keep two different pads, 'alice_to_bob.pad' and 'bob_to_alice.pad', as opposed to sharing the same pad for both directions of communication. With two separate pads, even if you each send a message simultaneously to the other with no advance planning, you still won't accidentally use any of the same pad data twice, assuming you let OneTime do its bookkeeping naturally. See http://en.wikipedia.org/wiki/One-time_pad for more information about one-time pads in general. OneTime is written by Karl Fogel and distributed under an MIT-style open source license; run 'onetime --license' or see the LICENSE file in the full distribution for complete licensing information. OneTime's home page is http://www.red-bean.com/onetime/.
This is the output of 'onetime --help':
OneTime version 2.0-beta6, an open source encryption program that uses one-time pads. Typical usage: onetime -e -p PAD MSG (encrypt; write output to 'MSG.onetime') onetime -d -p PAD MSG.onetime (decrypt; output loses '.onetime' suffix) Other usage modes: onetime [-e|-d] -p PAD -o OUTPUT INPUT (both INPUT and OUTPUT are files) onetime [-e|-d] -p PAD -o - INPUT (output goes to stdout) onetime [-e|-d] -p PAD (input from stdin, output to stdout) onetime [-e|-d] -p PAD -o OUTPUT (input from stdin, output to OUTPUT) OneTime remembers what ranges of what pad files have been used, and avoids re-using those ranges when encrypting, by keeping records in ~/.onetime/. All options: -e Encrypt -d Decrypt -p PAD | --pad=PAD Use PAD for pad data. -o OUT | --output=OUT Output to file OUT ("-" for stdout) --offset=N Control the pad data start offset -n | --no-trace Leave no record of pad usage in your config -C DIR | --config=DIR Specify DIR (instead of ~/.onetime) as config area; '-' for DIR means use no config area (implies -n) --show-id Show a pad's ID; used with -p only --intro Show an introduction to OneTime and one-time pads -v | -V | --version Show version information --license Show full open source license information --pad-help Show help on how to generate one-time pads -? | -h | --help Show usage
And here is how to generate a one-time pad (this is the output of 'onetime --pad-help'):
How to Generate a One-Time Pad ============================== These commands will create a pad on computers that have a local source of random bytes at /dev/random and the ability to copy those bytes with the `dd` command. Most GNU/Linux computers can do this. $ mkdir -p ~/.onetime $ dd if=/dev/random of=~/.onetime/to_foo.pad bs=1000 count=10000 That command will place a 10 megabyte pad in ~/.onetime/to_foo.pad (1000000 bytes is one megabyte). That pad will be good for encrypting 10 megabytes of data before it should be retired. If you anticipate sending more than 10 megabytes of data with the same pad, you will want to replace 10 with a higher count. On some computers, large pads may take a long time, even days, to generate. Just let dd work while you do other things. (Although you can go faster by using /dev/urandom instead of /dev/random, opinion is divided on whether the random numbers from /dev/urandom are good enough; to be safe, we recommend /dev/random, but see http://www.2uo.de/myths-about-urandom/ for more discussion.) To encrypt a file named WALLET.DAT with that pad: $ onetime -e -p ~/.onetime/to_foo.pad WALLET.DAT (produces WALLET.DAT.onetime).
Note that the one-time pad method depends completely on the quality of the pad data: if the pad is not truly random, the security of your messages cannot be guaranteed. So to use OneTime reliably, you need a source of good random data to create pad files. On modern Linux systems, the /dev/random device is probably good enough (here's how to do it, but note I haven't done the math myself — I'm just taking other people's word for it). Elsewhere, you're on your own.
Also, if the same pad data is used to encrypt different messages — no matter how similar or different those messages are — then the security of the system can be greatly compromised. Never encrypt different messages with the same stretch of pad! Doing so could reveal some or all of the used pad to eavesdroppers. OneTime's default behavior is to always avoid reusing pad data, unless you tell it otherwise.
Recommended practice: if you are Alice communicating with Bob, then keep two different pads, alice_to_bob.pad and bob_to_alice.pad, as opposed to sharing the same pad for both directions of communication. With two separate pads, even if you each send a message simultaneously to the other with no advance planning, you still won't accidentally use any of the same pad data twice, assuming you let OneTime do its bookkeeping naturally.