Image of the glider from the Game of Life by John Conway
Skip to content

The One-Time Pad Hard Drive

I devised a system to use the one-time pad (OTP) using nothing more than a hard drive. It goes something like this:

  1. Meet in person with identical size hard drives.
  2. Encrypt the hard drive.
  3. File the drive with random keys of incrementing size.
  4. Devise an alorithm for using the keys.
  5. Unmount the drive.
  6. Enjoy the OTP for encryption/decryption.
  7. Profit.

Step number 3 requires creating files of incrementing size 1 byte at a time from 1 byte until the drive is filled. If your drive is 8 GB in size, then this should be approximately 131,000 files, with the smallest file as 1 byte, and the largest file as 131,000 bytes. Further, the keys should be filled with cryptographically secure random data. Using /dev/random would be preferred, however it will block when entropy is depleted. Using a hardware true random number generator to keey the entropy pool filled, like the Entropy Key from Simtec Electronics would work. Last, the hard drives must have the exact same keys on both. So, it would probably be best to create the random keys on one drive first, then rsync its contents to the second drive.

Step number 4 is important, as you want to make sure that the recipient of your message uses the same keys you did to encrypt the message. So, an algorithm needs to be devised for using the keys. The OTP requires that the key be the same length or longer than the message wishing to be encrypted/decrypted. Because the keys are of incrementing size from 1 byte on up, you should be able to choose a key of matching size for your plaintext. If not, you can combine different sized keys until the full length of the message is met with the keys. That combination of keys becomes the OTP. So, it would probably be best to have a computer program or script find the right keys for the job. Thus, both the sender and recipient will be using the same keys. The OTP uses the XOR operation to encrypt and decrypt the messages. XOR works, because it completely undoes what is done, provided the same key is used on both messages, and it's fast and clean.

Step number 6 implies the encrypting and decrypting of messages using the OTP keys "out in the field". However, after the keys have been used, THEY MUST NEVER BE USED AGAIN. You could simply delete the file(s), or securely shred the file(s), if you have your tinfoil hat on. Regardless, their intent is to be thrown away after use. This is because if the key(s) are used more than once, then the key(s) can be derived from the multiple encrypted messages that shared the key(s). So, encrypt/decrypt the message, then remove the key(s) from the drive. After the keys have been used up on the hard drive, meet in person again to refill the drives.

This works, because Claude Shannon proved that the OTP contains perfect secrecy, meaning that there is no information contained in the ciphertext that will give you any clues as to how it was derived, such as no patterns or structures in the data. This means that the encrypted text cannot be decrypted unless the key is known. This assumes that the key is truly random, the key is never used again, and the secrecy of the key is kept in tact. It's clean, it works, and it's practical enough to use day-to-day. So, if you want to test out using the OTP to encrypt and decrypt messages, this is your tool.

{ 6 } Comments

  1. Jason using Firefox 14.0.1 on Ubuntu 64 bits | August 26, 2012 at 10:01 am | Permalink

    I don't see the benefit of having varying key sizes. Why not just use a drive filled with random data, and use a system where you start at byte 0, and for each message exchanged, you walk through the key bytes and consume whatever is needed for that message size. If we've previously exchanged 31337 bytes of messages in the past, then the next message uses key data offset from 31338 through to the exact length of the new message.

    There is a race condition problem if you both want to send a message at the same time, you may accidentally start at the same offset. If you both send messages using the same OTP then you've just broken the security. But then your proposal has this problem too, so it would need to be solved in any case.

  2. Aaron Toponce using Google Chrome 22.0.1229.2 on Mac OS | August 26, 2012 at 10:24 am | Permalink

    I thought about that, and the reason I decided against it, is because then every first byte starts with 0 or 1 for every message exchanged. While the rest of the data may be random, that first byte is not.

  3. Alan Bell using Firefox 15.0 on Ubuntu 64 bits | August 26, 2012 at 2:46 pm | Permalink

    better to use standard length key sizes, and have one set per direction. If you try and match the key size to the message then you give away the exact message length. If they are all 1024 bytes long or some other convenient size then you waste some bits (big deal) but leak less about your message. In fact if your keys are all bigger than any message you might want to send then you are giving away the least. The problem with one time pad is the requirement of distribution of the keys in advance. You can't really securely negotiate keys over the wire.

  4. Aaron Toponce using Debian IceWeasel 10.0.6 on GNU/Linux 64 bits | August 26, 2012 at 7:09 pm | Permalink

    If the key is not the same length as the message, then it's not a one-time pad. That's how it offers perfect secrecy.

  5. Nikos Fotiou using Safari 534.30 on Android | August 27, 2012 at 7:56 am | Permalink

    Can you please elaborate comment 2 a bit more?

  6. Aaron Toponce using Google Chrome 21.0.1180.75 on GNU/Linux 64 bits | August 27, 2012 at 11:00 am | Permalink

    Encrypting the hard drive? Well, if the drive is lost or stolen, you don't want the bad guys to have access to the keys, do you? So, use something like LUKS, TrueCrypt or eCryptfs to encrypt the keys on the drive.

{ 1 } Trackback

  1. […] OTP can be an effective and practical way to send messages securely. I mentioned almost a year ago, of a way to create a USB hard drive with a OTP on the drive. Both the sender and the recipient have an exact copy of the drive, along with a software utility […]

Post a Comment

Your email is never published nor shared.

Switch to our mobile site