Once again ... the one-time pad is a theoretical cipher, because it presupposes the existence of perfect secret-communication conditions for the mutual exchange of a perfectly-random and yet also perfectly-secure key ... held by the two parties and by no one else.

If you could actually do that, you would have no need of a cipher. Just use this magical communication channel to exchange your messages directly.

One time pads are a practical block encryption tool, not just a theoretical one. However they require a secure channel for the pad exchange (usually in person). They are totally impractical as a stream cipher, which is what the OP wan asking.

Remember that every application of the one-time pad is a stream-cipher and could not possibly be anything else. There must be a one-to-one correspondence between message bytes and key bytes. The one-time pad cannot for example be used to exchange the key of a conventional cryptosystem: the pad bytes must be applied directly to the message such that pad bytes are never, ever, ever used again. The pad must be the only cryptographic concealment that is used. A perfect duplicate copy of the pad must be held by both parties; a perfectly secure way of obtaining knowledge of the pad must exist; the pad contents must in fact be perfectly random; a perfectly error-free communication channel must be used; pad bytes must be used once and only once with no overlaps; you can never repeat the message nor any part of it in any less-secure system.

If any of these (impossible in real life) prerequisites are not followed, the theoretical security of the one-time pad is broken. Russian spies were captured because the tabulating machinery used to produce their "random" pads had a slight mechanical bias that could be exploited; and because, when transmission errors occurred, they tended to re-use the same portion of their (precious and irreplaceable) pads. British spy-lords received a message (the last one ever received from that agent), in the clear, explaining that his maid had accidentally washed the handkerchief upon which his key-material had been secretly printed. There was of course no way to replace it, and, without it, no way to communicate with that agent (who most likely killed himself). There is a fascinating book, Between Silk and Cyanide, which was written by one of the British experts who had to design, and deploy, and troubleshoot, the secret communication systems of their resistance agents. The author was, of necessity, the ultimate pragmatist.

Real-world practical crypto is easy: just add an "s" after that "http" and bingo! Security is on. Everything about the system is public knowledge ... except the keys. Gigabytes of data can be transmitted with no loss of security. Both parties can know the identity of the party with whom they are communicating, and they know that the message received is as-tendered. I could never send anything to you with an OTP unless I had first met with you in person and with perfect security given you a secret of more-than-sufficient length that both of us could then maintain with perfect security with no possibility of it being lost forever in the maid's washbucket.

And we come full circle. Yes, in a sense it is a stream cipher, but it is more of a block cipher as it operates on a block of data and both the pad and the block are the same length.

Thee is no need for the pad data to be totally random to provide security, so long as the messages are not of considerable length and the pads are never reused. It suffers from the same limitation, if you choose to call it such, that all symmetric encryption schemes do - the need for a secure channel to transfer the keys/pad.

And SSL - as currently implemented by most of the net has been repeatedly show to be open to compromise and will remain so until everyone using SSL moves beyond TLS1.0 MITM is perfectly feasible with SSL.

Citation needed.

Perhaps I should have said "practical security" Yes to have theoretical Shannon (perfect) security the pad data must be random.

However due to the non-reuse of the pad, and the transience of the material typically encrypted using this method, the degree of randomness can be minimal in most cases.

Sorry I thought I posted this reply yesterday but apparently closed the tab before doing so.

I think some of the cynics here saying one-time pads are not practical are missing a few points. It's true that OTPs would be useless as a drop-in replacement for, say, HTTPS, because it is impractical to send a pad to all of your potential customers in advance. However, that doesn't mean there are no scenarios where a OTP would be useful.

Many have said that OTPs are pointless because if you have a secure channel for exchanging keys, you can just use that channel to send the messages. Some have already made the obvious rebuttal that a message sent physically to the other side of the planet would take longer - at least a few hours for such a delivery by fighter jet, compared with milliseconds for an IP packet.

A few have conceded that although practical for sending short messages, OTPs are not practical for encrypting a whole network interface or stream. This may have been true in the past but nowadays we can carry 50 terabytes in a briefcase. Even if we maxed-out a 512Kbps connection (a speed we're all familiar with), it would take 27 years to exhaust a pad of that size.

Finally, although vulnerable to rubber-hose attacks or double agent couriers, multiple pads can be sent via different channels and only one needs to arrive without being intercepted; 99 out of 100 pads could be intercepted and that would be just as unbreakable as if none of them had. And there's no reason you can't combine OTPs with an asymmetric cipher for good measure.

Consider the department of defence of a nuclear state in the middle of a cold-war. They want to be able to control their nukes from their headquarters, and although their telecomms lines are well-guarded, they understand that wire-tapping is still a risk. Rumours has it that their enemies are on the verge of developing a quantum computer, or that they already have. Espionage is so rife that they are not even confident that none of the generals who might generate a key or pad are themselves spies.

Therefore, to keep their missile control lines secure, each general generates their own one-time pad and transports it to the missile silos. Each pad is applied in series to the stream so, having witnessed the safe arrival and installation of at least their own pad, they are confident that the line cannot be cracked by wire-tappers.

It's true that most people do not require this much security, and it is a lot of hassle. But OTP stream encryption it is not merely theoretical as some claim. I'd even consider using it to cut through corporate bureaucracy: "So, you want to install a remote-controlled surveillance robot in our secure data centre? Over WIFI? This will never pass our security policies; WEP is easy to crack, I heard someone even used the EC2 cloud to brute-force WPA recently." - "Ah, but I will just carry a 1TB HDD across the road every couple of weeks. I trust myself to deliver it, and it'll be absolutely unbreakable" - "OK then". Why keep playing catch-up when you can just skip to the end?

If only one one-time-pad were compromised, then all copies would be.

Filling a 2 terabyte drive with random numbers would take a very long time. Generating random numbers is a difficult process. You need hardware to generate a lot. You would need such a 2 terabyte drive for each recipient. A central office would have to keep a copy of each and track which drive to use for which remote user.

For something like a VPN tunnel, traffic is used constantly even if you aren't sending a file.

One time pads were used in US submarines during WW1. When a sub left port, the captain would carry on board a suitcase full of pads. This allowed secure communication between HQ and the sub, but not between any other points. For one sub to talk to another, an entire set of pads would be needed. The Germans found out we were using OTP and adopted the technology, but used them improperly. As a result, we were able to decrypt some of their uboat traffic.

Each courier has a different one-time pad. They are applied in series at each end.

These are trivial problems. Hardware RNGs can produce random numbers at megabits per second.

As I said, you could max-out a 512Kbps connection for 27 years with a single briefcase worth of pads.

As I said it's not suitable for every scenario - but that doesn't mean it doesn't have any practical applications at all. Actually, with satellite technology, sub-to-sub communication can happen via the HQ so that wouldn't be a problem nowadays anyway.

If you want practical security, does one time pad really have any advantage over a well tested symmetric cipher (eg AES)?
So a one time pad is like an infinitely long key, but that doesn't mean you have perfect security.
What if the last general is the traitor, couldn't he just pick up everyone else's pads from the silo?

Cut through corporate bureaucracy? Dream on. More like: "OTP isn't listed as an approved algorithm in FIPS 140-2, that will never pass our security policies."

"Among symmetric key encryption algorithms, only the one-time pad can be proven to be secure against any adversary - no matter how much computing power is available."

Faster computers, disruptive technologies, mathematical discoveries. To be fair to nay-sayers, and to put things in perspective; if someone actually invented a practical quantum computer tomorrow, although OTP would protect your business's privacy, you're going to have much, much bigger problems when all the world's financial institutions, governments, etc. are pried open for the world to see and start to crumble around you. That is not a criticism of OTP, though.

If one of the generals is traitorous and has access to key stores, AES isn't going to be much use either. That was not the point of the example.

OK that's a fair point. No-one ever claimed bureaucracy had to be rational. That doesn't make OTPs any less secure though. All that means is that the US government would prefer it if people didn't use unbreakable crypto algorithms. Funny that. </tinfoilhat>

I don't really see that as practical, though. Having a computer that can break a cipher in 10^49 years instead of 10^50 years isn't going to matter. An attacker isn't going to break into your system by waiting for disruptive technologies or mathematical discoveries.

A quantum computer would break RSA and ECC, but not symmetric ciphers. There are asymmetric ciphers that can't be broken by a quantum computer, but they have much longer keys so they aren't widely used. I'm not trying to criticize OTP, just that its theoretical perfect security does not in fact give you actual perfect security.

Yeah, algorithms are only a small part of security.

When the US had export restrictions on cryptographic software, was OTP listed as restricted? I guess it's so simple there's nothing much to restrict, but apparently they were more worried about the "non-perfect" algorithms getting into the hands of enemies...

A block cipher is, by definition, a cipher that applies some algorithm upon some "block" of data and then applies some permutation of that algorithm upon the next "block." A one-time pad is, as I said, by definition "a stream cipher" because any one character of the key key is applied once-and-only-once upon exactly one character of the plaintext ... and then it is never used again. A one-time pad is therefore useful only for a plaintext that is no larger than its own length ... inclusive of any and all transmission errors.

The difference between one-time pad and symmetric cipher is that the length of the key of a symmetric cipher was much shorter than that of the message itself. The masking stream that was applied to the message was algorithmically computed, so to speak, from the key. In the one-time pad, no such algorithmic relationship exists, and the content of the key is "non-algorithmically, perfectly, random." In short, splendidly unpractical.

Hence, we have zeroed-in on three very practical approaches:

1. "The key," whatever it is, must somehow generate an extremely unpredictable sequence, even though every detail of the algorithm used to produce the sequence from the key is known.
2. It must be absolutely unfeasible to deduce exactly which key was used to produce a particular sequence, from any sort of examination of the sequence itself.
3. The two parties to a conversation must be able to exchange a secret (i.e. "a key") under conditions of non-security.
4. During a conversation, and without disrupting the parties to the conversation in any way, it must be necessary to (with absolute reliability...) switch keys on-the-fly.

If we can manage to do that, then we can indeed achieve "pragmatic security" for our exchanges, without losing any of the other equally-important attributes of such exchanges: sender identification, message integrity, and privacy.

OTP, of course, isn't "an algorithm" at all. In the OTP scenario, indeed, there by definition cannot be "an algorithm," since the encrypting-stream is perfect randomness. If the encryption stream consists of "8-bit bytes," then within that stream there must be exactly a 1-in-256 probability for every single byte, irrespective of any and all bytes that may have preceded it or that may follow it. If the statistical characteristics of the stream are, however slightly, different from this, then the OTP does not have any degree of "security" whatsoever!

And this is the mathematical downfall of the OTP: everything that might or might not be said about its "security" depends totally and exclusively upon this mathematically perfectly random key, which somehow is shared under conditions of mathematically perfect security between exactly two and no more than two parties ... in advance.

As I have said: "if you could somehow manage to actually do that, then you would have no need for a cipher at all!" It was fine for Alan Turing's theses, but not for anything else.

Ok here's a practical example of OTP use, one I've actually seen used. No truly "random" data anywhere!

And to be tradition meet Alice and Bob!

Alice has some important confidential material she needs to send to Bob. Unfortunately they are currently on opposite sides of the country and have no means of acquiring a secure channel to send each other keys.

Alice reminds Bob in conversation of the song she liked so much at the party last month and asks if he has a copy of CD? If he does play it and think of her. Bob has or gets a copy of the CD containing the song in question and waits for Alice's material.

Alice copies the CD into a digital file, uses it as an OTP against the material she's sending to BOB and then send Bob the encrypted file. When he receives it, Bob makes a digital copy of the CD and using it as the OTP retrieves Alice's material.

1) info on the key was transmitted in the clear using knowledge held by the parties involved.
2) the key itself was never compromised and was avialable without being transmitted over any channel

Even if Eve intercepts the material she has no idea of the key, or the encryption method. Even if she is at the same party and may have overheard the discussion, the song itself is not the key, merely a mutually understood reference between Alice and Bob.

The limitation in this particular case is that the message length cannot exceed the album length. A similar technique can be used using digital books (in assorted languages).


While not formally robust, and not something you'd want to use for classified material, it is a practical solution under many circumstances. It's basically the "book code" meets the one time pad.