|↑↑ Home||↑ Net & Web|
A one-time pad is simply a form of encryption where the key is as long as the plaintext. If this key (the one-time pad) is used only once, cryptanalysis has nothing to grab on to, and the encryption is absolutely secure.
In discussions about computer security, one tends to hear little about one-time pads compared to other encryption methods. This may be because there is nothing new about one-time pads. It does not mean that they are obsolete, though they have some drawbacks of their own.
The most obvious drawback of a one-time pad is that the large pad data has to be transferred somehow (the key distribution problem). This is especially awkward if the amount of data to be transmitted securely is large; obviously distributing a pad once that can be used for years is much less of a hassle than distributing one every fortnight. The pad also needs to be stored securely, and is best destroyed after use, or the transmitted data recorded by an attacker could be decoded retroactively. And the pad itself needs to consist of (ideally) perfectly random data.
Still, in an age where internet service providers and search engine operators are grabbing all information they can, and government agencies take an increasing interest in supposedly private communication, it may have its applications. The one thing one-time pad encryption is unbeatable against is men in the middle.
Inspired by these possible applications and the simplicity of the method, I have written a small TCP relay server that encrypts or decrypts traffic in both directions with one-time pads (C source here). Encryption/decryption is performed by an exclusive or operation between the message and the pad. Two one-time pad files are used, one for each communication direction. They are read backwards from the end, and are truncated when the server exits, so that it starts at the next available byte when restarted. The relay server opens one TCP listening socket and one normal TCP socket that it connects somewhere (according to its command line) when a client connects on the listening socket. That way, the same program can be used at both communication endpoints.
On its own, this little program is not much use. It merely keeps track of the pad files, does the XOR operation and passes data on. In order to attach an application in a way useful to you, you may want to look at socat, a general-purpose relay server that allows attaching a shell or a readline command line to a network socket bidirectionally, among many other things. Attaching a command line at one endpoint and a shell (via a pseudo-terminal) at the other amounts to a very secure one-time-pad remote shell connection (otpsh, anyone?). Other applications will also be easy to realize using shell script wrappers around otptunnel and socat.
One useful application that is slightly tricky to set up is a tunnel for an SSH connection. In SSH parlance, this is "proxying" rather than tunneling (which would be SSH providing the tunnel for something else). On the server, we start otptunnel so that it connects to the SSH server:
otptunnel pad1 pad2 1234 127.0.0.1:22 &
Because SSH expects its "proxying" command to communicate via stdin, we have to use socat to connect to our one-time-pad encryption server on the client side. So we start otptunnel so it connects to its counterpart on the server, and use a socat command as a proxy command for SSH:
otptunnel pad1 pad2 5678 server:1234 & ssh -o ProxyCommand="socat - tcp:127.0.0.1:5678" user@server
This should connect to the server's SSH server. (pad1 and pad2 of course have to have the same content on both systems.) otptunnel augments the SSH encryption by one-time-pad encryption but retains all SSH features.
Of course this is something of a proof-of-principle implementation that may have drawbacks in some situations. It is single-threaded and transfers data in both directions in turn, and may therefore not be best for high-bandwidth or low-latency applications. It does not overwrite the parts of the pad files it has used, so they may be recoverable. The relay servers at both ends of the communication may get out of sync if one is killed while transfer is inprogress, due to the unavoidable race condition between transmitting the encrypted data and updating the read offset. But if you have a use for it, have fun.
TOS / Impressum