ottools: tools for encrypting files with one-time pads

Xyne · 2013-02-27 11:22:08

Project page: http://xyne.archlinux.ca/projects/otextract/

Update

The package was originally named "otsplit" as it only contained that tool. I have since added "otextract" (and maybe others by the time you read this) and renamed the package "ottools". The original post follows. For up-to-date information, check the project page.

Original Post

otsplit (one-time split) is a file-splitting utility based on the idea of one-time pads. There are two splitting modes. One will use a random input source (/dev/urandom by default) to generate n-1 files and then generate 1 file that can be combined with them to recreate the original file. The other mode will use a pre-existing one-time pad to generate a single output file.

In the first case the file can only be recovered with all of the generated files. In the second case it can only be recovered with the single output file and the input pad. Note that this means that if even one of the required files is lost, the data will be completely unrecoverable. That is a feature, not a bug.

I wrote this a while ago as a quick distraction while procrastinating on something else. After rediscovering it today I decided to clean it up and release it. I expect that there are common tools that do this already, possibly with security features that I have not even considered.

Some usage ideas:

Exchange a one-time pad on a CD/DVD/usb drive with someone in person and then use otsplit to securely share files via email etc.
Create an archive of files that no one should see until after your death and distribute the files to people you know. Leave instructions and a list of people who received files to be read out at your funeral. Laugh maniacally as you ponder their obliviousness before the paranoia slowly consumes you and you frantically devise a plan to ensure the destruction of at least one file.
Use it to securely host tar archives across different cloud storage providers (assuming that no provider can access the other files).
Become an international (wo)man of mystery with a 70s wardrobe and use it as one of many tools to combat comically incapable supervillains with underwater lairs.
Smuggle information out of countries with oppressive regimes.
Speak with a heavy stereotypical Russian accent while using it and refer to file recipients as comrades of the glorious people's revolution.
Don't.

Last edited by Xyne (2013-02-28 06:53:28)

Barrucadu · 2013-02-27 11:48:55

IIRC /dev/urandom isn't considered cryptographically secure as it does magic trickery to ensure it never runs out of entropy. /dev/random is, I think, but it has the downside of blocking whenever it runs out of entropy.

Xyne · 2013-02-27 11:59:17

Barrucadu wrote:

IIRC /dev/urandom isn't considered cryptographically secure as it does magic trickery to ensure it never runs out of entropy. /dev/random is, I think, but it has the downside of blocking whenever it runs out of entropy.

Correct.

I have set /dev/urandom as the default because it should be "good enough" for most purposes. The random input source is configurable and can be set to /dev/random or a dedicated entropy source if necessary.

progandy · 2013-02-27 13:08:04

Barrucadu wrote:

IIRC /dev/urandom isn't considered cryptographically secure as it does magic trickery to ensure it never runs out of entropy. /dev/random is, I think, but it has the downside of blocking whenever it runs out of entropy.

There is always the haveged daemon if you need a more random data with better quality than urandom

Xyne · 2013-02-28 05:44:29

The package now includes a second utility, "extract-chunk". It can be used to extract an arbitrary, contiguous section of a file with optional support for excising it from the source file after extraction.

It should be useful for one-time pads (analogy: ripping out pages to ensure they are used only once).

Other changes along with some new sections can be found on the project page.

Xyne · 2013-02-28 06:58:28

Namingway strikes again:

package name: otsplit -> ottools
extract-chunk -> otextract

deepsoul · 2013-03-04 22:28:50

Interesting to find this now - just a few months ago I wrote a small TCP relay that encrypts using one-time pads. It would complement your file encryption tools (though it is not packaged ready to use). I have also given some thought to obtaining non-deterministic random numbers and hit on using sound card noise. While the statistical properties of the result may not be perfect, it may still be preferable because it is not determined by an algorithm.

Xyne · 2013-03-04 23:18:00

I like the idea of otptunnel. It's too bad that it can't be used to transfer pads (I mean, each transferred bit would cost one pad bit resulting in zero net gain)

Then again, you could use that to mask network traffic. Whenever the connection is not transferring encrypted data it could transfer a new encrypted pad equal in length to the remaining pad. The network stream would appear constant to eavesdroppers with no indication of where the actual data begins or ends. In essence you would be recycling the remaining pad. I'm just thinking out loud here so I may be missing something glaringly obvious, but I don't think it would have any effect on security provided each new pad is itself secure (truly random, etc.)

Reading through your page also made me realize that I had not considered securely wiping the pad. In most cases that should probably be left to the user to ensure that the best method is used, but otextract shifts the file data forward and just truncates the end of the file. I'll look into zero-padding the end and syncing to disk before truncating.

I've seen entropy collectors for sound cards before too and they are indeed interesting. There are approaches that use webcam input too (e.g. video_entropyd), and there's also havage (with matching package in the repos). What are your thoughts on those? What about multiplexing the signals from multiple sources? Essentially, if you get just one random bit from any source in the combined stream then that position is random. The more streams you have, the greater the chance of a given bit being truly random (obviously depending on quality of the sources).

(yeah, I ramble when I'm tired)

deepsoul · 2013-03-06 20:26:54

Sending new one-time pads in between encrypted payloads is an ingenious idea! It should really be undetectable.

But it has also made me aware that my suggested use for remote shell commands has a drawback: The size and timing of transmissions could still be observed and allow some educated guesses. But then, the same is probably true of SSH.

Regarding wiping data securely, you can never be sure on modern filesystems, because some of it may have been copied to the journal (see caveat note in "man shred").

Thank you for the links to video_entropyd/audio_entropyd and havage. I had not heard of them before. I cannot really say anything much about them (I'm not that much of an expert) except that they are probably more sophisticated than what I have been doing. From what I have heard, the kernel combines sources of entropy in a smart way, also adding in a pseudo-RNG for less bias AFAIK. If you feed random audio bits through that, the result is likely better than using them directly.

The reason I thought of using audio noise is that you get quite a lot of random bits - for example, 11 kB/s per channel if you have two noise bits per sample at CD sampling speeds. Most sound cards allow rather larger sampling rates and 6 or 8 channels. Besides, you need no administrator privileges to access audio inputs, as opposed to hooking a daemon into the kernel RNG.

Arch Linux

#1 2013-02-27 11:22:08