12

Occasionally I hear people say that one-time pads are "useless" or even "broken".

"modern cryptography knows more security definitions, under some of which the one-time pad is completely broken." -- How do we know a cryptographic primitive won't fail suddenly?

...

One time pad: why is it useless in practice?

...

"we don’t need (and shouldn’t want) to use one-time pads"

...

"The one-time pad is not a semantically secure encryption algorithm."

...

"One-time pads may be theoretically secure, but they are not secure in a practical sense." -- Bruce Schneier

What specifically are these "modern ... security definitions", and how exactly is the one-time pad completely broken?

David Cary
  • 5,664
  • 4
  • 21
  • 35
  • 2
    I think he meant broken in the sense that it does not provide authenticity – Richie Frame Jun 05 '15 at 01:47
  • One thing to note is that on recent versions of Chrome, you are using CHACHA20_POLY1035 to connect to Google. CHACHA20 is essentially a hash-function (may not be usable as a hash-function, because they have different security requirements) that is used as a CSRNG to generate the key stream for a one-time-pad. – Bardi Harborow Jun 05 '15 at 03:32
  • 2
    @Bardi Hardborow: chacha20 as used e.g. in Chrome is a stream cipher (which keystream generator is generated by a CSPRNG, which is a PRF applied to a counter and a key); it is not an OTP, which keystream is true random, rather than derived from a key. – fgrieu Jun 05 '15 at 10:56
  • 1
    A onetime pad involves 3 components: plaintext, cyphertext, & keypad. Any party gets any two components, they can derive the third. In modern cryptography, we care about resisting attacks where an adversary has two of the components. Hence onetime pads are not applicable in most modern cryptographic attack scenarios. – recursion.ninja Jun 05 '15 at 14:17
  • 1
    What? That's not even remotely correct. An attacker, even in a modern context, with the ciphertext and key can recover the plaintext. – Stephen Touset Jun 05 '15 at 20:27
  • 1
    @StephenTouset I was obviously referencing weakness against the following: known-plaintext attack, chosen-plaintext attack, chosen-cyphertext attack, adaptive chosen-cyphertext. – recursion.ninja Jun 05 '15 at 20:50
  • @CodesInChaos: I realize the original title "Has the one-time pad been broken?" was a little provocative, but I think "Does the one-time-pad meet modern security definitions?" is ambiguous. The answer is either trivially "no" (a OTP doesn't do or meet anything; people and machines do things and meet people) or trivially yes (The modern definition of a OTP has critical details not present in early cryptography definitions, and of course a real OTP matches that definition, even though other things that people might mistakenly call a OTP do not). Feel free to tweak the title further. – David Cary Jun 06 '15 at 01:56
  • @recursion.ninja I don't think it makes OTP inherently insecure, in fact, nothing can be more secure than it. – Darcy Sutton Jan 16 '23 at 10:56

4 Answers4

22

Modern security has moved beyond looking just at passive attacks (in which the attacker is just a passive eavesdropper seeking to learn what was said); attackers are generally considered to be able and willing to pull off active attacks of various types (in which the attacker can modify or forge messages to achieve some goal). One-time pads are extremely vulnerable to modification; if an attacker knows that a message says "Pay Robert \$100,000", they can trivially change it to "Pay Joseph \$999,999". They share this property with all stream ciphers; if your ciphertext is the plaintext XOR a keystream, then an attacker who knows $P_1$ and $C_1$ can easily compute $C_2=C_1\oplus (P_1\oplus P_2)$, which decrypts to $P_2$. Working around that requires some way to verify message authenticity, which a one-time pad doesn't do (and doesn't try to do). This is provided by message authentication codes (MACs), or by a cryptosystem that combines authentication and encryption (like AES-GCM).

Also, many security properties literally do not apply to OTPs, because the properties are along the lines of "given the ability to encrypt multiple messages with the key, do X."

Uselessness is broader: even if you just need confidentiality, OTPs have serious issues for usability. That's because a OTP key has to be as long as the message and transmitted in secret; cryptography is most useful when you just need to transmit a little information secretly to encrypt a lot of stuff. An OTP is only as secure as the key exchange, so to be useful the keys have to be exchanged without relying on cryptography for security (else you're not getting perfect security). There are a few cases where they work well (like distributing in person to someone who's about to go on a mission and will need to send stuff back to you over an insecure channel), but they're rare.

cpast
  • 3,587
  • 1
  • 15
  • 27
  • They also reveal the length of the message, if used without padding. And when you use them with padding you run into all the issues that can cause. – SAI Peregrinus Jun 05 '15 at 02:54
  • @SAIPeregrinus So do all stream ciphers. Revealing the length of the message is usually not considered an issue. – cpast Jun 05 '15 at 03:40
  • Actually, an OTP-type system can provide integrity; it works pretty much like a MAC, except instead of having a fixed key, we consume part of the keystream. – poncho Jun 05 '15 at 03:45
  • @poncho An OTP-type system, yes. An OTP itself, no. – cpast Jun 05 '15 at 03:46
  • It is possible to encrypt several messages with an OTP. It is not possible to do it securely. – fkraiem Jun 05 '15 at 03:52
  • 2
    @fkraiem There is a logical contradiction within your statement. Remember, in OTP, the O and T stand for "One Time". If the stream is used to encrypt more than one message, it is by definition not an OTP. – Erwan Legrand Jun 05 '15 at 08:13
  • Well it depends on the definition you operate under. To me, a cryptosystem is given by the three algorithms (key generation, encryption and decryption). There is no way to specify in the algorithm that it must be used only once, so to me it's the same algorithm no matter how many times you use it. – fkraiem Jun 05 '15 at 08:16
  • 1
    @fkraiem In the case of OTPs, the keystream generation algorithm is as follows: take the key which sits on top of the stack or, if the stack is empty, fail hard. – Erwan Legrand Jun 05 '15 at 09:07
  • 1
    @ErwanLegrand That's not how I would define it (and since there is probably no universally agreed upon definition, I guess this discussion is pointless). – fkraiem Jun 05 '15 at 09:23
  • cpast is wrong in his/her example that the same key is used twice to encrypt P1 and P2, which is not an one time pad – user1589188 Jun 05 '15 at 10:51
  • @user You have misread the example. $C_2$ is an attacker-made forged ciphertext. – cpast Jun 05 '15 at 13:59
  • Do all stream ciphers use XOR? That is, does not generating a keystream which is XOR'd (or XNOR'd) with the plaintext imply that a cipher is not a stream cipher? I would have expected that a stream cipher would be defined as any cipher which operates one bit at a time. – user253751 Jun 06 '15 at 06:09
  • "That's because a OTP key has to be as long as the message and transmitted in secret; cryptography is most useful when you just need to transmit a little information secretly to encrypt a lot of stuff. " That isn't the point. The point is that OTP reduces the problem to THE SAME DAMNED PROBLEM. Transmitting a message of Length X securely to Bob. The only part that has changed is that the message (the key) can be sent ahead of time. If you can send the key secure, why bother, JUST SEND THE MESSAGE INSTEAD OF THE KEY. – Aron Jun 06 '15 at 10:06
  • 1
    @Aron How do I send a message that I don't have yet? – 8bittree Feb 19 '19 at 20:30
  • @Aron You're wildly mistaken. When you send the message is often far more important than how long it is. For instance, you can send a virtually unlimited amount of information securely using a trusted courier, but you can't do that on a moment's notice. The point of cryptography there actually isn't reducing how long of a secret you need, it's letting you send secure messages on demand. – cpast Feb 20 '19 at 01:15
  • @cpast that is exactly what I was trying to get at. One time pad is only as effective as your ability to securely transfer a large amount of entropy. – Aron Feb 20 '19 at 02:26
  • @Aron But that's not the same problem as sending the message. They're two different problems: "send X bits of entropy right now" vs. "send X bits of entropy at some point but it isn't time-sensitive." For an example, one of the cases where OTPs were useful was the DC-Moscow hotline, where OTPs could be securely exchanged on a routine basis to support urgent messages during a nuclear crisis. Sending a diplomatic bag to Moscow was easy, but the problem was sending a secure message as two fleets approached each other. – cpast Feb 20 '19 at 03:39
  • @cpast yes. But for the vast majority of threat models its not a huge difference. I agree OTP is very useful iff you have a high latency high bandwidth and extremely secure channel. But in practice, that only exists for state actors and the extremely wealthy. I trust my Asymmetric cypher key exchange more that "USPS guy". – Aron Feb 20 '19 at 04:09
  • I can't afford the services or loyalty of Captain "you need to cut my hand off to get these keys" America to send my entropy. – Aron Feb 20 '19 at 04:12
5

fkraiem's answer is correct, but more context is required, in my opinion.

The one-time pad (the theoretical device) has not been broken. But real-world systems based on the one-time pad have failed in practice.

Systems based on one-time pads have failed in the past because key material has been reused, either by mistake or because the sender had ran out of fresh key material.

Remember, with a one-time pad, the secret key needs to be as least as long as the message.

Thus, modern cryptosystems are designed so that this issue no longer happens. They use a short key and a nonce (https://en.wikipedia.org/wiki/Cryptographic_nonce) and in the case of stream ciphers generate a keystream which is as long as required.

Note that the same issues (running out of keystream or using the same keystream twice) could theoretically happen with a modern cryptosystem, if cycles are found within the key stream or all possible nonces have been used. (And in some cases, it does, because of implementation issues.) In order to prevent this, the nonce space is made large enough. The exhaustion of a 128 bit nonce space will not happen.

Erwan Legrand
  • 239
  • 1
  • 7
  • 2
    +1 one time pad has been proven to be the most secure encryption scheme one can possibly achieved, but at the same time the most impractical solution to everyday security needs. – user1589188 Jun 05 '15 at 11:01
5

In a lot of cases OTP will be completely impractical. If instead of a truly random pad you use a pseudo random pad, you will have something a lot more practical. But it is no longer OTP, and the security proofs about OTP means nothing in that case. I think this is the essence of the Bruce Schneier quote you mention.

If we for a moment ignore the impractical aspect of it and assume a setting in which the communicating parties have shared a random key in advance, then why might OTP be considered broken?

First of all OTP is all about confidentiality. A lot of people when they first learn about cryptography think that confidentiality is the most important aspect of cryptography. But in most cases it isn't. Integrity is usually more important. In fact confidentiality without integrity is rarely useful.

So all that provable confidentiality of OTP is useless unless you have provable integrity to go along with it. Luckily Wegman and Carter showed how to do that many years ago. Just like OTP the MAC by Wegman and Carter consumes key bits every time it is used. But the good news is that the MAC only consumes a constant number of bits each time, so much fewer bits are used for the MAC than for OTP which uses as many key bits as the length of the message.

Making it somewhat practical

The combination of OTP and Wegman Carter MAC (or a derivative) is proven secure. But to make it practical one need a source for a long common secret bitstring. I have only ever heard about one way to produce such a key if it wasn't shared among the two parties in advance, and that is through quantum cryptography.

Quantum cryptography does however require an authenticated classical channel. So you cannot bootstrap quantum cryptography without first sharing some secret between the communicating parties. But if you have shared enough key bits for a Wegman Carter MAC, then you can use quantum cryptography to produce a longer shared key for further communication.

The key material produced by quantum cryptography can be used to exchange messages on a classical channel using OTP + Wegman Carter for security. One of course has to save enough bits for the MAC on another round of the quantum communication to refill the pool of key bits.

kasperd
  • 1,377
  • 1
  • 10
  • 23
0

Modern definitions of security require being able to securely encrypt a large number of messages with the same key, which is by definition not possible with a one-time pad.

fkraiem
  • 8,112
  • 2
  • 27
  • 38