One Time Pads and “Bit Flip” Attacks
Clash Royale CLAN TAG#URR8PPP
$begingroup$
One Time Pads and Vulnerability to "Bit-Flip" Attacks:
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. Given my own professional experience using One Time Pads, I found these claims astonishing and was interested in learning if there was chink in the OTP armor rendering it an insecure system to protect data secrecy.
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
one-time-pad
$endgroup$
add a comment |
$begingroup$
One Time Pads and Vulnerability to "Bit-Flip" Attacks:
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. Given my own professional experience using One Time Pads, I found these claims astonishing and was interested in learning if there was chink in the OTP armor rendering it an insecure system to protect data secrecy.
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
one-time-pad
$endgroup$
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– SEJPM♦
Feb 11 at 18:21
$begingroup$
I am perplexed; the answer should be polynomial mac but it's been blasted off wikipeida.
$endgroup$
– Joshua
Feb 11 at 23:26
add a comment |
$begingroup$
One Time Pads and Vulnerability to "Bit-Flip" Attacks:
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. Given my own professional experience using One Time Pads, I found these claims astonishing and was interested in learning if there was chink in the OTP armor rendering it an insecure system to protect data secrecy.
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
one-time-pad
$endgroup$
One Time Pads and Vulnerability to "Bit-Flip" Attacks:
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. Given my own professional experience using One Time Pads, I found these claims astonishing and was interested in learning if there was chink in the OTP armor rendering it an insecure system to protect data secrecy.
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
one-time-pad
one-time-pad
edited Feb 13 at 13:03
F1Linux
asked Feb 11 at 15:47
F1LinuxF1Linux
9019
9019
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– SEJPM♦
Feb 11 at 18:21
$begingroup$
I am perplexed; the answer should be polynomial mac but it's been blasted off wikipeida.
$endgroup$
– Joshua
Feb 11 at 23:26
add a comment |
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– SEJPM♦
Feb 11 at 18:21
$begingroup$
I am perplexed; the answer should be polynomial mac but it's been blasted off wikipeida.
$endgroup$
– Joshua
Feb 11 at 23:26
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– SEJPM♦
Feb 11 at 18:21
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– SEJPM♦
Feb 11 at 18:21
$begingroup$
I am perplexed; the answer should be polynomial mac but it's been blasted off wikipeida.
$endgroup$
– Joshua
Feb 11 at 23:26
$begingroup$
I am perplexed; the answer should be polynomial mac but it's been blasted off wikipeida.
$endgroup$
– Joshua
Feb 11 at 23:26
add a comment |
4 Answers
4
active
oldest
votes
$begingroup$
accepted wisdom that OTP encrypted messages are secure & unbreakable
OTP encrypted messages are secure & unbreakable assuming the pad is secret, uniformly random, and not reused... and the message does not otherwise leak! The last point is where the "Bit Flip" attack comes to play.
Imagine the message is conventionally a digit send in ASCII, and parsed as such by the receiver after decryption; and that the context tells the adversary that a particular message is 1
or 2
, that is the bitstring 00110001
or 00110010
. With the OTP (or a stream cipher), the adversary can flip the 5th bit of ciphertext, and know that changes the plaintext to 00111001
or 00111010
, that is the character 9
or :
. Now if the adversary can sense whether the receiving system accepts the result as a digit, or rejects it, the confidentiality is lost!
More generally, when users of cryptography need encryption for confidentialitty, they tend to additionally need assurance of integrity and origin. The OTP only gives confidentiality, and as illustrated not unconditionally in some quite practical cases.
However, assurance of integrity can be obtained with an information-theoretic substitude to a MAC, or universal hash, such as Carter-Wegman; and when the OTP is shared among only two parties that gives assurance of origin. That consumes some of the OTP, but manageably so. And it can help mitigate the above attack (an altered message will be rejected before it is tested that it is decimal).
There remains two reasons making the OTP impractical:
- It is easy for an adversary to mount a denial of service attack that de-synchronize sender and receiver (that can be solved to a degree, but is not trivial)
- The random pad must be sent in advance by secure means, and kept secret on both sides.
$endgroup$
1
$begingroup$
Your analysis reinforces the accepted wisdom to operate OTP systems in anologue- not digital- modes. Most on this group assume that OTP is a computer thingy, which is an unsafe assumption. You can never be 100% sure there's no trojans or keyloggers on a PC, so nobody with anything that important to communicate would use a computer. And an attacker can't engage in modifying messages if they don't know who the communicating parties are and the time and modality of their communications- which will probably not be a computer. And if they knew who you were, you'd already be compromised ;-)
$endgroup$
– F1Linux
Feb 11 at 18:32
$begingroup$
Using a MAC will impose a minimum usable message size. If the threat model does not include MITM attacks, and if synchronization is provided via some means like a known shared clock, OTP can work down to a message size of one bit.
$endgroup$
– supercat
Feb 11 at 19:18
add a comment |
$begingroup$
There are different objectives when it comes to security. One objective is to make messages confidential. An OTP provides this in an information-theoretical secure way. Of course, the premise of OTP is that the key stream is fully random, which is hard to prove conclusively.
Other security goals could be maintaining message integrity: making sure that the message isn't tampered with or otherwise altered and message authenticity: making sure that the message that is received is the message that the sender wanted to send to the receiver. These goals are not covered by an OTP, as a message can be tampered with during transit or when in storage.
If an adversary can only listen and can not interfere with the message then we talk about an eavesdropper. As no interference is possible, it is generally not needed to secure the message to achieve integrity / authenticity. In that case an OTP is sufficient to protect the message, as it provides the confidentiality required. Trying to decipher a confidential message without changing the transport of the message itself or performing any actions involving the participants is called a passive attack.
However, for most systems, we have to assume that active attacks - such as man-in-the-middle attacks - are possible. In that case the attacker may try to tamper the message in transit, or send messages of his own to the receiver. If any invalid message is accepted then integrity and authenticity of the messages is obviously not achieved. One method of changing the messages is a bit flip attack, but it would also be possible to change the size of the message or tamper it in any other way. The bitflip attack is however powerful because it allows an attacker to flip any specific bit of the plaintext.
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. I found these claims astonishing and was interested in learning more.
I don't see that in the articles you posted to. Yes, the articles pointed out the flaws of schemes that uses OTP's and the drawbacks of OTP's, but I don't see any name calling (calling somebody an "amateur" would be a strange way of name calling, a good amateur can be better than many professionals out there, if we take the terms by their literal meaning).
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Correct. OTP's provide perfect confidentiality (well, except for the message length or timing, never forget that), so no attack can change that. Note that the system may still leak information about a tampered message though. For instance, if computation based on the received message may trigger specific errors, and those errors can be detected by an adversary, then plaintext oracle attacks may leak information about the contents of the message (any action that depends on the plaintext message may do that, of course).
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Of course they are; they must be thin on details as the methods of altering a ciphertext message in transit depend fully on the system. Unfortunately, there are many ways that active attacks are possible, and you ignore them at your peril.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
I think you are naive if you think that it is easy to detect tampered messages without leaking data. Similarly, I think you incorrectly assume that active attacks are commonly not possible. These are serious issues and it is unwise to ignore them in the best of cases.
In the end, key management with one-time-pads is awkward at best and outright impractical and dangerous at worst. We've got secure schemes such as authenticated cipher modes (ChaCha20/Poly1305 and AES/GCM, for instance) that provide symmetric encryption that include small key sizes as well as integrity / authenticity of the message. These are more secure to use for most systems, certainly compared to schemes that just use an OTP (rather than an OTP combined with a MAC authentication tag, for instance).
Sure, it may be possible that some schemes are better off using an OTP. Those are however so uncommon that OTP should be considered a red flag when it comes to cryptography. It commonly means that the designer of the scheme doesn't know about or severely underestimates the limitations and drawbacks of OTP's.
The fact is that an OTP protects you against breaking of other symmetric cipher algorithms / implementations. That's currently not much of an issue for most ciphers. If you can make a conscious, well founded decision that an OTP is required to protect you against such attacks then go for it. But please be aware of the listed limitations and drawbacks of OTPs.
$endgroup$
add a comment |
$begingroup$
One way to address this question is to give an example of a real-world attack that relies on being able to modify a ciphertext in a way that alters the resulting plaintext in a predictable, attacker-controllable manner. And there's a very notable example from last year: 2018's EFAIL attack on encrypted email clients:
The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
And further down, describing one of the variants of the attack, note the two sentences I've boldfaced:
Second, we describe the novel CBC/CFB gadget attacks which abuse vulnerabilities in the specification of OpenPGP and S/MIME to exfiltrate the plaintext. The diagram below describes the idea of CBC gadgets in S/MIME. Because of the specifics of the CBC mode of operation, an attacker can precisely modify plaintext blocks if she knows the plaintext. S/MIME encrypted emails usually start with "Content-type: multipart/signed" so the attacker knows at least one full block of plaintext as shown in (a). She can then form a canonical plaintext block whose content is all zeros as shown in (b). We call the block pair X and C0 a CBC gadget. In step (c), she then repeatedly appends CBC gadgets to inject an image tag into the encrypted plaintext. This creates a single encrypted body part that exfiltrates its own plaintext when the user opens the attacker email.
This is a little bit dense, but the idea behind the "exfiltration" is tricking the email client into decrypting a modified message that will have the original plaintext inside a URL inside an HTML img
tag, so that the email client will request that URL when the user opens the email. The attacker points that URL at their own servers, and monitors their access logs to learn the plaintexts.
I'll close with some informal remarks that might help you:
- Most classical cryptography existed in a world where there were no computers. Humans decrypted messages and interpreted their content using common sense.
- Modern cryptography exists in a world where computers are ubiquitous. Messages are decrypted by computers that blindly perform automated actions on the decrypted content.
Therefore, while classical cryptography often cared only about whether encryption provided confidentiality for messages, modern cryptography cares just as much about providing message authenticity—it's not enough that a passive eavesdropper be unable to learn anything new about the plaintext from its ciphertext, we also need to prevent an active attacker who has partial knowledge about the plaintext (e.g., the email format headers) from leveraging that to modify ciphertexts in ways that produce controllable changes in plaintext that the recipient (a computer, not a person!) will admit as authentic.
So the modern standard that encryption algorithms are expected to live up to is authenticated encryption. One-time pads guarantee perfect confidentiality, but don't guarantee message authenticity at all.
$endgroup$
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:38
1
$begingroup$
-1: I don't think this is a good example, as the EFAIL attack that is described above does not work with OTPs. Crucially, an attacker cannot create a new email that he sends to the victim, nor can he create additional canonical OTP blocks.
$endgroup$
– Fax
Feb 12 at 17:38
$begingroup$
I do have to agree with @Fax above. Although the EFAIL attack is a clear demonstration how unauthenticated messages can be attacked using active attacks (and it is therefore a good example what happens if you don't authenticate your messages) I don't see how this would work for an OTP.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:56
1
$begingroup$
I certainly do not claim EFAIL would work with an OTP, but I still think it's a good example of why ciphertext malleability is a serious problem that modern cryptography must guard again. The solution—make sure that all forged ciphertexts are rejected except with negligible probability—is insensitive to the details of which attacks work against which ciphers. And @Fax, I don't think your "crucial" part is actually crucial; using a forgery to trick the email client to reveal the plaintext more than bad enough already.
$endgroup$
– Luis Casillas
Feb 12 at 23:21
$begingroup$
@LuisCasillas Although you're comparing apples and oranges- OTP is symmetric and Public Key is asymmetric, I really like your approach trying to make an evidenced-based proof rather than relying on pure theoretical. And your answer inadvertently shed light on security issues with Public Key systems many might not have been aware of. So +1 for a scientific approach you took to your answer.
$endgroup$
– F1Linux
Feb 14 at 12:09
|
show 4 more comments
$begingroup$
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent.
The pillars of information security are confidentiality, integrity, and availability. (integrity and authenticity are sometimes used interchangeably).
Encryption is a tool for providing confidentiality. It does not by itself provide integrity.
Integrity is provided by a MAC, digital signature, or authenticated encryption scheme.
An adversaries ability to modify ciphertexts is a problem that is inherent to encryption schemes in general and is not specific to OTPs.
The question "Why should I use Authenticated Encryption instead of just encryption" covers this pretty thoroughly and fgrieu's answer provides another example.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to.
OTPs offer perfect secrecy, which means that given a ciphertext an adversary cannot learn anything more about the plaintext than they already knew. This last part is key: A OTP does not mean that an adversary knows nothing about the plaintext already, it means that they cannot use a ciphertext to learn more than they already knew.
The security models for confidentiality consider the following scenarios:
- Ciphertext only attack
- Known plaintext attack
- Chosen plaintext attack
- e.g. the adversary has access to an encryption oracle
- Chosen ciphertext attack
- e.g. the adversary has access to a decryption oracle
The ciphertext only attack model cannot in general be relied upon. Typically at least a known-plaintext attack model needs to be considered.
The reason for this is because messages are not (generally) strings of uniformly random bits. This means that the plaintext consists of less than 1 bit of entropy (uncertainty) per bit of message. This means that an adversary knows or can guess some of the contents of the message.
This is actually not as unreasonable as it may seem at first: Most real-world communications possess structure that is probably known to the adversary. For example, an HTTP request has certain fields that are always and/or commonly present, and the values of those fields are typically structured as well.
OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course.
This is a big "if". There are a lot of prerequisites, and it is easy to fail at them even when the stakes are very high.
The main problem that modern cryptographic techniques solve is not symmetric encryption to secure messages (which is relatively easy), but key management.
Key management for OTPs is maximumly difficult. For the modern world (e,g. the internet), it is prohibitively so.
This is why the apparently easy, fast, and obvious solution of using OTPs is not supported by modern protocols or standardized for use (unlike algorithms such as AES or Salsa20, which do have official standards and a specification).
The reason why people advocate against OTPs is not because they are insecure, but because they are practically unusable.
$endgroup$
$begingroup$
1TB HD, tamper detection seals, SATA locked, $100 I think OTP is usable now.
$endgroup$
– Joshua
Feb 11 at 23:35
1
$begingroup$
@Joshua For the most common use case of securing the internet, each web site would need to exchange (in person) keys with ever user. Assuming that they opted for a 1TB drive per user to minimize the number of required exchanges (and use the figure you quoted), a web site with only 10,000 users would need to spend $1,000,000 dollars to secure their connections. In reality, it would cost far more then $100 per user for secure redundant storage, and you could never do the key hand-off part to begin with in real life. There are many many reasons it is unusable other than the cost of storage.
$endgroup$
– Ella Rose♦
Feb 12 at 0:17
$begingroup$
Depends on who you are securing against. If against a state actor the internet is not secure now. Lavabit only stood because the government tried to make an example of them rather than use an NSA level attack. Getting a cert only requires demonstrating control of the domain (even before let's encrypt) and the feds could do that easily.
$endgroup$
– Joshua
Feb 12 at 14:29
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
return StackExchange.using("mathjaxEditing", function ()
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
);
);
, "mathjax-editing");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "281"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f67233%2fone-time-pads-and-bit-flip-attacks%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
$begingroup$
accepted wisdom that OTP encrypted messages are secure & unbreakable
OTP encrypted messages are secure & unbreakable assuming the pad is secret, uniformly random, and not reused... and the message does not otherwise leak! The last point is where the "Bit Flip" attack comes to play.
Imagine the message is conventionally a digit send in ASCII, and parsed as such by the receiver after decryption; and that the context tells the adversary that a particular message is 1
or 2
, that is the bitstring 00110001
or 00110010
. With the OTP (or a stream cipher), the adversary can flip the 5th bit of ciphertext, and know that changes the plaintext to 00111001
or 00111010
, that is the character 9
or :
. Now if the adversary can sense whether the receiving system accepts the result as a digit, or rejects it, the confidentiality is lost!
More generally, when users of cryptography need encryption for confidentialitty, they tend to additionally need assurance of integrity and origin. The OTP only gives confidentiality, and as illustrated not unconditionally in some quite practical cases.
However, assurance of integrity can be obtained with an information-theoretic substitude to a MAC, or universal hash, such as Carter-Wegman; and when the OTP is shared among only two parties that gives assurance of origin. That consumes some of the OTP, but manageably so. And it can help mitigate the above attack (an altered message will be rejected before it is tested that it is decimal).
There remains two reasons making the OTP impractical:
- It is easy for an adversary to mount a denial of service attack that de-synchronize sender and receiver (that can be solved to a degree, but is not trivial)
- The random pad must be sent in advance by secure means, and kept secret on both sides.
$endgroup$
1
$begingroup$
Your analysis reinforces the accepted wisdom to operate OTP systems in anologue- not digital- modes. Most on this group assume that OTP is a computer thingy, which is an unsafe assumption. You can never be 100% sure there's no trojans or keyloggers on a PC, so nobody with anything that important to communicate would use a computer. And an attacker can't engage in modifying messages if they don't know who the communicating parties are and the time and modality of their communications- which will probably not be a computer. And if they knew who you were, you'd already be compromised ;-)
$endgroup$
– F1Linux
Feb 11 at 18:32
$begingroup$
Using a MAC will impose a minimum usable message size. If the threat model does not include MITM attacks, and if synchronization is provided via some means like a known shared clock, OTP can work down to a message size of one bit.
$endgroup$
– supercat
Feb 11 at 19:18
add a comment |
$begingroup$
accepted wisdom that OTP encrypted messages are secure & unbreakable
OTP encrypted messages are secure & unbreakable assuming the pad is secret, uniformly random, and not reused... and the message does not otherwise leak! The last point is where the "Bit Flip" attack comes to play.
Imagine the message is conventionally a digit send in ASCII, and parsed as such by the receiver after decryption; and that the context tells the adversary that a particular message is 1
or 2
, that is the bitstring 00110001
or 00110010
. With the OTP (or a stream cipher), the adversary can flip the 5th bit of ciphertext, and know that changes the plaintext to 00111001
or 00111010
, that is the character 9
or :
. Now if the adversary can sense whether the receiving system accepts the result as a digit, or rejects it, the confidentiality is lost!
More generally, when users of cryptography need encryption for confidentialitty, they tend to additionally need assurance of integrity and origin. The OTP only gives confidentiality, and as illustrated not unconditionally in some quite practical cases.
However, assurance of integrity can be obtained with an information-theoretic substitude to a MAC, or universal hash, such as Carter-Wegman; and when the OTP is shared among only two parties that gives assurance of origin. That consumes some of the OTP, but manageably so. And it can help mitigate the above attack (an altered message will be rejected before it is tested that it is decimal).
There remains two reasons making the OTP impractical:
- It is easy for an adversary to mount a denial of service attack that de-synchronize sender and receiver (that can be solved to a degree, but is not trivial)
- The random pad must be sent in advance by secure means, and kept secret on both sides.
$endgroup$
1
$begingroup$
Your analysis reinforces the accepted wisdom to operate OTP systems in anologue- not digital- modes. Most on this group assume that OTP is a computer thingy, which is an unsafe assumption. You can never be 100% sure there's no trojans or keyloggers on a PC, so nobody with anything that important to communicate would use a computer. And an attacker can't engage in modifying messages if they don't know who the communicating parties are and the time and modality of their communications- which will probably not be a computer. And if they knew who you were, you'd already be compromised ;-)
$endgroup$
– F1Linux
Feb 11 at 18:32
$begingroup$
Using a MAC will impose a minimum usable message size. If the threat model does not include MITM attacks, and if synchronization is provided via some means like a known shared clock, OTP can work down to a message size of one bit.
$endgroup$
– supercat
Feb 11 at 19:18
add a comment |
$begingroup$
accepted wisdom that OTP encrypted messages are secure & unbreakable
OTP encrypted messages are secure & unbreakable assuming the pad is secret, uniformly random, and not reused... and the message does not otherwise leak! The last point is where the "Bit Flip" attack comes to play.
Imagine the message is conventionally a digit send in ASCII, and parsed as such by the receiver after decryption; and that the context tells the adversary that a particular message is 1
or 2
, that is the bitstring 00110001
or 00110010
. With the OTP (or a stream cipher), the adversary can flip the 5th bit of ciphertext, and know that changes the plaintext to 00111001
or 00111010
, that is the character 9
or :
. Now if the adversary can sense whether the receiving system accepts the result as a digit, or rejects it, the confidentiality is lost!
More generally, when users of cryptography need encryption for confidentialitty, they tend to additionally need assurance of integrity and origin. The OTP only gives confidentiality, and as illustrated not unconditionally in some quite practical cases.
However, assurance of integrity can be obtained with an information-theoretic substitude to a MAC, or universal hash, such as Carter-Wegman; and when the OTP is shared among only two parties that gives assurance of origin. That consumes some of the OTP, but manageably so. And it can help mitigate the above attack (an altered message will be rejected before it is tested that it is decimal).
There remains two reasons making the OTP impractical:
- It is easy for an adversary to mount a denial of service attack that de-synchronize sender and receiver (that can be solved to a degree, but is not trivial)
- The random pad must be sent in advance by secure means, and kept secret on both sides.
$endgroup$
accepted wisdom that OTP encrypted messages are secure & unbreakable
OTP encrypted messages are secure & unbreakable assuming the pad is secret, uniformly random, and not reused... and the message does not otherwise leak! The last point is where the "Bit Flip" attack comes to play.
Imagine the message is conventionally a digit send in ASCII, and parsed as such by the receiver after decryption; and that the context tells the adversary that a particular message is 1
or 2
, that is the bitstring 00110001
or 00110010
. With the OTP (or a stream cipher), the adversary can flip the 5th bit of ciphertext, and know that changes the plaintext to 00111001
or 00111010
, that is the character 9
or :
. Now if the adversary can sense whether the receiving system accepts the result as a digit, or rejects it, the confidentiality is lost!
More generally, when users of cryptography need encryption for confidentialitty, they tend to additionally need assurance of integrity and origin. The OTP only gives confidentiality, and as illustrated not unconditionally in some quite practical cases.
However, assurance of integrity can be obtained with an information-theoretic substitude to a MAC, or universal hash, such as Carter-Wegman; and when the OTP is shared among only two parties that gives assurance of origin. That consumes some of the OTP, but manageably so. And it can help mitigate the above attack (an altered message will be rejected before it is tested that it is decimal).
There remains two reasons making the OTP impractical:
- It is easy for an adversary to mount a denial of service attack that de-synchronize sender and receiver (that can be solved to a degree, but is not trivial)
- The random pad must be sent in advance by secure means, and kept secret on both sides.
edited Feb 13 at 6:18
answered Feb 11 at 17:38
fgrieufgrieu
80.8k7172342
80.8k7172342
1
$begingroup$
Your analysis reinforces the accepted wisdom to operate OTP systems in anologue- not digital- modes. Most on this group assume that OTP is a computer thingy, which is an unsafe assumption. You can never be 100% sure there's no trojans or keyloggers on a PC, so nobody with anything that important to communicate would use a computer. And an attacker can't engage in modifying messages if they don't know who the communicating parties are and the time and modality of their communications- which will probably not be a computer. And if they knew who you were, you'd already be compromised ;-)
$endgroup$
– F1Linux
Feb 11 at 18:32
$begingroup$
Using a MAC will impose a minimum usable message size. If the threat model does not include MITM attacks, and if synchronization is provided via some means like a known shared clock, OTP can work down to a message size of one bit.
$endgroup$
– supercat
Feb 11 at 19:18
add a comment |
1
$begingroup$
Your analysis reinforces the accepted wisdom to operate OTP systems in anologue- not digital- modes. Most on this group assume that OTP is a computer thingy, which is an unsafe assumption. You can never be 100% sure there's no trojans or keyloggers on a PC, so nobody with anything that important to communicate would use a computer. And an attacker can't engage in modifying messages if they don't know who the communicating parties are and the time and modality of their communications- which will probably not be a computer. And if they knew who you were, you'd already be compromised ;-)
$endgroup$
– F1Linux
Feb 11 at 18:32
$begingroup$
Using a MAC will impose a minimum usable message size. If the threat model does not include MITM attacks, and if synchronization is provided via some means like a known shared clock, OTP can work down to a message size of one bit.
$endgroup$
– supercat
Feb 11 at 19:18
1
1
$begingroup$
Your analysis reinforces the accepted wisdom to operate OTP systems in anologue- not digital- modes. Most on this group assume that OTP is a computer thingy, which is an unsafe assumption. You can never be 100% sure there's no trojans or keyloggers on a PC, so nobody with anything that important to communicate would use a computer. And an attacker can't engage in modifying messages if they don't know who the communicating parties are and the time and modality of their communications- which will probably not be a computer. And if they knew who you were, you'd already be compromised ;-)
$endgroup$
– F1Linux
Feb 11 at 18:32
$begingroup$
Your analysis reinforces the accepted wisdom to operate OTP systems in anologue- not digital- modes. Most on this group assume that OTP is a computer thingy, which is an unsafe assumption. You can never be 100% sure there's no trojans or keyloggers on a PC, so nobody with anything that important to communicate would use a computer. And an attacker can't engage in modifying messages if they don't know who the communicating parties are and the time and modality of their communications- which will probably not be a computer. And if they knew who you were, you'd already be compromised ;-)
$endgroup$
– F1Linux
Feb 11 at 18:32
$begingroup$
Using a MAC will impose a minimum usable message size. If the threat model does not include MITM attacks, and if synchronization is provided via some means like a known shared clock, OTP can work down to a message size of one bit.
$endgroup$
– supercat
Feb 11 at 19:18
$begingroup$
Using a MAC will impose a minimum usable message size. If the threat model does not include MITM attacks, and if synchronization is provided via some means like a known shared clock, OTP can work down to a message size of one bit.
$endgroup$
– supercat
Feb 11 at 19:18
add a comment |
$begingroup$
There are different objectives when it comes to security. One objective is to make messages confidential. An OTP provides this in an information-theoretical secure way. Of course, the premise of OTP is that the key stream is fully random, which is hard to prove conclusively.
Other security goals could be maintaining message integrity: making sure that the message isn't tampered with or otherwise altered and message authenticity: making sure that the message that is received is the message that the sender wanted to send to the receiver. These goals are not covered by an OTP, as a message can be tampered with during transit or when in storage.
If an adversary can only listen and can not interfere with the message then we talk about an eavesdropper. As no interference is possible, it is generally not needed to secure the message to achieve integrity / authenticity. In that case an OTP is sufficient to protect the message, as it provides the confidentiality required. Trying to decipher a confidential message without changing the transport of the message itself or performing any actions involving the participants is called a passive attack.
However, for most systems, we have to assume that active attacks - such as man-in-the-middle attacks - are possible. In that case the attacker may try to tamper the message in transit, or send messages of his own to the receiver. If any invalid message is accepted then integrity and authenticity of the messages is obviously not achieved. One method of changing the messages is a bit flip attack, but it would also be possible to change the size of the message or tamper it in any other way. The bitflip attack is however powerful because it allows an attacker to flip any specific bit of the plaintext.
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. I found these claims astonishing and was interested in learning more.
I don't see that in the articles you posted to. Yes, the articles pointed out the flaws of schemes that uses OTP's and the drawbacks of OTP's, but I don't see any name calling (calling somebody an "amateur" would be a strange way of name calling, a good amateur can be better than many professionals out there, if we take the terms by their literal meaning).
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Correct. OTP's provide perfect confidentiality (well, except for the message length or timing, never forget that), so no attack can change that. Note that the system may still leak information about a tampered message though. For instance, if computation based on the received message may trigger specific errors, and those errors can be detected by an adversary, then plaintext oracle attacks may leak information about the contents of the message (any action that depends on the plaintext message may do that, of course).
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Of course they are; they must be thin on details as the methods of altering a ciphertext message in transit depend fully on the system. Unfortunately, there are many ways that active attacks are possible, and you ignore them at your peril.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
I think you are naive if you think that it is easy to detect tampered messages without leaking data. Similarly, I think you incorrectly assume that active attacks are commonly not possible. These are serious issues and it is unwise to ignore them in the best of cases.
In the end, key management with one-time-pads is awkward at best and outright impractical and dangerous at worst. We've got secure schemes such as authenticated cipher modes (ChaCha20/Poly1305 and AES/GCM, for instance) that provide symmetric encryption that include small key sizes as well as integrity / authenticity of the message. These are more secure to use for most systems, certainly compared to schemes that just use an OTP (rather than an OTP combined with a MAC authentication tag, for instance).
Sure, it may be possible that some schemes are better off using an OTP. Those are however so uncommon that OTP should be considered a red flag when it comes to cryptography. It commonly means that the designer of the scheme doesn't know about or severely underestimates the limitations and drawbacks of OTP's.
The fact is that an OTP protects you against breaking of other symmetric cipher algorithms / implementations. That's currently not much of an issue for most ciphers. If you can make a conscious, well founded decision that an OTP is required to protect you against such attacks then go for it. But please be aware of the listed limitations and drawbacks of OTPs.
$endgroup$
add a comment |
$begingroup$
There are different objectives when it comes to security. One objective is to make messages confidential. An OTP provides this in an information-theoretical secure way. Of course, the premise of OTP is that the key stream is fully random, which is hard to prove conclusively.
Other security goals could be maintaining message integrity: making sure that the message isn't tampered with or otherwise altered and message authenticity: making sure that the message that is received is the message that the sender wanted to send to the receiver. These goals are not covered by an OTP, as a message can be tampered with during transit or when in storage.
If an adversary can only listen and can not interfere with the message then we talk about an eavesdropper. As no interference is possible, it is generally not needed to secure the message to achieve integrity / authenticity. In that case an OTP is sufficient to protect the message, as it provides the confidentiality required. Trying to decipher a confidential message without changing the transport of the message itself or performing any actions involving the participants is called a passive attack.
However, for most systems, we have to assume that active attacks - such as man-in-the-middle attacks - are possible. In that case the attacker may try to tamper the message in transit, or send messages of his own to the receiver. If any invalid message is accepted then integrity and authenticity of the messages is obviously not achieved. One method of changing the messages is a bit flip attack, but it would also be possible to change the size of the message or tamper it in any other way. The bitflip attack is however powerful because it allows an attacker to flip any specific bit of the plaintext.
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. I found these claims astonishing and was interested in learning more.
I don't see that in the articles you posted to. Yes, the articles pointed out the flaws of schemes that uses OTP's and the drawbacks of OTP's, but I don't see any name calling (calling somebody an "amateur" would be a strange way of name calling, a good amateur can be better than many professionals out there, if we take the terms by their literal meaning).
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Correct. OTP's provide perfect confidentiality (well, except for the message length or timing, never forget that), so no attack can change that. Note that the system may still leak information about a tampered message though. For instance, if computation based on the received message may trigger specific errors, and those errors can be detected by an adversary, then plaintext oracle attacks may leak information about the contents of the message (any action that depends on the plaintext message may do that, of course).
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Of course they are; they must be thin on details as the methods of altering a ciphertext message in transit depend fully on the system. Unfortunately, there are many ways that active attacks are possible, and you ignore them at your peril.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
I think you are naive if you think that it is easy to detect tampered messages without leaking data. Similarly, I think you incorrectly assume that active attacks are commonly not possible. These are serious issues and it is unwise to ignore them in the best of cases.
In the end, key management with one-time-pads is awkward at best and outright impractical and dangerous at worst. We've got secure schemes such as authenticated cipher modes (ChaCha20/Poly1305 and AES/GCM, for instance) that provide symmetric encryption that include small key sizes as well as integrity / authenticity of the message. These are more secure to use for most systems, certainly compared to schemes that just use an OTP (rather than an OTP combined with a MAC authentication tag, for instance).
Sure, it may be possible that some schemes are better off using an OTP. Those are however so uncommon that OTP should be considered a red flag when it comes to cryptography. It commonly means that the designer of the scheme doesn't know about or severely underestimates the limitations and drawbacks of OTP's.
The fact is that an OTP protects you against breaking of other symmetric cipher algorithms / implementations. That's currently not much of an issue for most ciphers. If you can make a conscious, well founded decision that an OTP is required to protect you against such attacks then go for it. But please be aware of the listed limitations and drawbacks of OTPs.
$endgroup$
add a comment |
$begingroup$
There are different objectives when it comes to security. One objective is to make messages confidential. An OTP provides this in an information-theoretical secure way. Of course, the premise of OTP is that the key stream is fully random, which is hard to prove conclusively.
Other security goals could be maintaining message integrity: making sure that the message isn't tampered with or otherwise altered and message authenticity: making sure that the message that is received is the message that the sender wanted to send to the receiver. These goals are not covered by an OTP, as a message can be tampered with during transit or when in storage.
If an adversary can only listen and can not interfere with the message then we talk about an eavesdropper. As no interference is possible, it is generally not needed to secure the message to achieve integrity / authenticity. In that case an OTP is sufficient to protect the message, as it provides the confidentiality required. Trying to decipher a confidential message without changing the transport of the message itself or performing any actions involving the participants is called a passive attack.
However, for most systems, we have to assume that active attacks - such as man-in-the-middle attacks - are possible. In that case the attacker may try to tamper the message in transit, or send messages of his own to the receiver. If any invalid message is accepted then integrity and authenticity of the messages is obviously not achieved. One method of changing the messages is a bit flip attack, but it would also be possible to change the size of the message or tamper it in any other way. The bitflip attack is however powerful because it allows an attacker to flip any specific bit of the plaintext.
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. I found these claims astonishing and was interested in learning more.
I don't see that in the articles you posted to. Yes, the articles pointed out the flaws of schemes that uses OTP's and the drawbacks of OTP's, but I don't see any name calling (calling somebody an "amateur" would be a strange way of name calling, a good amateur can be better than many professionals out there, if we take the terms by their literal meaning).
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Correct. OTP's provide perfect confidentiality (well, except for the message length or timing, never forget that), so no attack can change that. Note that the system may still leak information about a tampered message though. For instance, if computation based on the received message may trigger specific errors, and those errors can be detected by an adversary, then plaintext oracle attacks may leak information about the contents of the message (any action that depends on the plaintext message may do that, of course).
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Of course they are; they must be thin on details as the methods of altering a ciphertext message in transit depend fully on the system. Unfortunately, there are many ways that active attacks are possible, and you ignore them at your peril.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
I think you are naive if you think that it is easy to detect tampered messages without leaking data. Similarly, I think you incorrectly assume that active attacks are commonly not possible. These are serious issues and it is unwise to ignore them in the best of cases.
In the end, key management with one-time-pads is awkward at best and outright impractical and dangerous at worst. We've got secure schemes such as authenticated cipher modes (ChaCha20/Poly1305 and AES/GCM, for instance) that provide symmetric encryption that include small key sizes as well as integrity / authenticity of the message. These are more secure to use for most systems, certainly compared to schemes that just use an OTP (rather than an OTP combined with a MAC authentication tag, for instance).
Sure, it may be possible that some schemes are better off using an OTP. Those are however so uncommon that OTP should be considered a red flag when it comes to cryptography. It commonly means that the designer of the scheme doesn't know about or severely underestimates the limitations and drawbacks of OTP's.
The fact is that an OTP protects you against breaking of other symmetric cipher algorithms / implementations. That's currently not much of an issue for most ciphers. If you can make a conscious, well founded decision that an OTP is required to protect you against such attacks then go for it. But please be aware of the listed limitations and drawbacks of OTPs.
$endgroup$
There are different objectives when it comes to security. One objective is to make messages confidential. An OTP provides this in an information-theoretical secure way. Of course, the premise of OTP is that the key stream is fully random, which is hard to prove conclusively.
Other security goals could be maintaining message integrity: making sure that the message isn't tampered with or otherwise altered and message authenticity: making sure that the message that is received is the message that the sender wanted to send to the receiver. These goals are not covered by an OTP, as a message can be tampered with during transit or when in storage.
If an adversary can only listen and can not interfere with the message then we talk about an eavesdropper. As no interference is possible, it is generally not needed to secure the message to achieve integrity / authenticity. In that case an OTP is sufficient to protect the message, as it provides the confidentiality required. Trying to decipher a confidential message without changing the transport of the message itself or performing any actions involving the participants is called a passive attack.
However, for most systems, we have to assume that active attacks - such as man-in-the-middle attacks - are possible. In that case the attacker may try to tamper the message in transit, or send messages of his own to the receiver. If any invalid message is accepted then integrity and authenticity of the messages is obviously not achieved. One method of changing the messages is a bit flip attack, but it would also be possible to change the size of the message or tamper it in any other way. The bitflip attack is however powerful because it allows an attacker to flip any specific bit of the plaintext.
I've seen it in this group, and apparently there are a (small) number of voices on the 'net opining that those relying on OTP are essentially "amateurs" (or otherwise oblivious) to the possibility of "bit-flip" being a fatal flaw in OTP and they should NOT be used. I found these claims astonishing and was interested in learning more.
I don't see that in the articles you posted to. Yes, the articles pointed out the flaws of schemes that uses OTP's and the drawbacks of OTP's, but I don't see any name calling (calling somebody an "amateur" would be a strange way of name calling, a good amateur can be better than many professionals out there, if we take the terms by their literal meaning).
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent. But even tampering doesn't imply that the attacker can read the text they tampered with sans a key. So as far as I can see at this point, the secrets still remain protected.
Correct. OTP's provide perfect confidentiality (well, except for the message length or timing, never forget that), so no attack can change that. Note that the system may still leak information about a tampered message though. For instance, if computation based on the received message may trigger specific errors, and those errors can be detected by an adversary, then plaintext oracle attacks may leak information about the contents of the message (any action that depends on the plaintext message may do that, of course).
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to. Those decrying One Time Pads as an insecure, flawed system are thin on details how an attacker would obtain this key these key pieces of data.
Of course they are; they must be thin on details as the methods of altering a ciphertext message in transit depend fully on the system. Unfortunately, there are many ways that active attacks are possible, and you ignore them at your peril.
Such a claim is bold and it contravenes accepted wisdom that OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course. Am I missing something here?
I think you are naive if you think that it is easy to detect tampered messages without leaking data. Similarly, I think you incorrectly assume that active attacks are commonly not possible. These are serious issues and it is unwise to ignore them in the best of cases.
In the end, key management with one-time-pads is awkward at best and outright impractical and dangerous at worst. We've got secure schemes such as authenticated cipher modes (ChaCha20/Poly1305 and AES/GCM, for instance) that provide symmetric encryption that include small key sizes as well as integrity / authenticity of the message. These are more secure to use for most systems, certainly compared to schemes that just use an OTP (rather than an OTP combined with a MAC authentication tag, for instance).
Sure, it may be possible that some schemes are better off using an OTP. Those are however so uncommon that OTP should be considered a red flag when it comes to cryptography. It commonly means that the designer of the scheme doesn't know about or severely underestimates the limitations and drawbacks of OTP's.
The fact is that an OTP protects you against breaking of other symmetric cipher algorithms / implementations. That's currently not much of an issue for most ciphers. If you can make a conscious, well founded decision that an OTP is required to protect you against such attacks then go for it. But please be aware of the listed limitations and drawbacks of OTPs.
edited Feb 12 at 18:14
answered Feb 11 at 18:15
Maarten Bodewes♦Maarten Bodewes
55.1k679196
55.1k679196
add a comment |
add a comment |
$begingroup$
One way to address this question is to give an example of a real-world attack that relies on being able to modify a ciphertext in a way that alters the resulting plaintext in a predictable, attacker-controllable manner. And there's a very notable example from last year: 2018's EFAIL attack on encrypted email clients:
The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
And further down, describing one of the variants of the attack, note the two sentences I've boldfaced:
Second, we describe the novel CBC/CFB gadget attacks which abuse vulnerabilities in the specification of OpenPGP and S/MIME to exfiltrate the plaintext. The diagram below describes the idea of CBC gadgets in S/MIME. Because of the specifics of the CBC mode of operation, an attacker can precisely modify plaintext blocks if she knows the plaintext. S/MIME encrypted emails usually start with "Content-type: multipart/signed" so the attacker knows at least one full block of plaintext as shown in (a). She can then form a canonical plaintext block whose content is all zeros as shown in (b). We call the block pair X and C0 a CBC gadget. In step (c), she then repeatedly appends CBC gadgets to inject an image tag into the encrypted plaintext. This creates a single encrypted body part that exfiltrates its own plaintext when the user opens the attacker email.
This is a little bit dense, but the idea behind the "exfiltration" is tricking the email client into decrypting a modified message that will have the original plaintext inside a URL inside an HTML img
tag, so that the email client will request that URL when the user opens the email. The attacker points that URL at their own servers, and monitors their access logs to learn the plaintexts.
I'll close with some informal remarks that might help you:
- Most classical cryptography existed in a world where there were no computers. Humans decrypted messages and interpreted their content using common sense.
- Modern cryptography exists in a world where computers are ubiquitous. Messages are decrypted by computers that blindly perform automated actions on the decrypted content.
Therefore, while classical cryptography often cared only about whether encryption provided confidentiality for messages, modern cryptography cares just as much about providing message authenticity—it's not enough that a passive eavesdropper be unable to learn anything new about the plaintext from its ciphertext, we also need to prevent an active attacker who has partial knowledge about the plaintext (e.g., the email format headers) from leveraging that to modify ciphertexts in ways that produce controllable changes in plaintext that the recipient (a computer, not a person!) will admit as authentic.
So the modern standard that encryption algorithms are expected to live up to is authenticated encryption. One-time pads guarantee perfect confidentiality, but don't guarantee message authenticity at all.
$endgroup$
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:38
1
$begingroup$
-1: I don't think this is a good example, as the EFAIL attack that is described above does not work with OTPs. Crucially, an attacker cannot create a new email that he sends to the victim, nor can he create additional canonical OTP blocks.
$endgroup$
– Fax
Feb 12 at 17:38
$begingroup$
I do have to agree with @Fax above. Although the EFAIL attack is a clear demonstration how unauthenticated messages can be attacked using active attacks (and it is therefore a good example what happens if you don't authenticate your messages) I don't see how this would work for an OTP.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:56
1
$begingroup$
I certainly do not claim EFAIL would work with an OTP, but I still think it's a good example of why ciphertext malleability is a serious problem that modern cryptography must guard again. The solution—make sure that all forged ciphertexts are rejected except with negligible probability—is insensitive to the details of which attacks work against which ciphers. And @Fax, I don't think your "crucial" part is actually crucial; using a forgery to trick the email client to reveal the plaintext more than bad enough already.
$endgroup$
– Luis Casillas
Feb 12 at 23:21
$begingroup$
@LuisCasillas Although you're comparing apples and oranges- OTP is symmetric and Public Key is asymmetric, I really like your approach trying to make an evidenced-based proof rather than relying on pure theoretical. And your answer inadvertently shed light on security issues with Public Key systems many might not have been aware of. So +1 for a scientific approach you took to your answer.
$endgroup$
– F1Linux
Feb 14 at 12:09
|
show 4 more comments
$begingroup$
One way to address this question is to give an example of a real-world attack that relies on being able to modify a ciphertext in a way that alters the resulting plaintext in a predictable, attacker-controllable manner. And there's a very notable example from last year: 2018's EFAIL attack on encrypted email clients:
The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
And further down, describing one of the variants of the attack, note the two sentences I've boldfaced:
Second, we describe the novel CBC/CFB gadget attacks which abuse vulnerabilities in the specification of OpenPGP and S/MIME to exfiltrate the plaintext. The diagram below describes the idea of CBC gadgets in S/MIME. Because of the specifics of the CBC mode of operation, an attacker can precisely modify plaintext blocks if she knows the plaintext. S/MIME encrypted emails usually start with "Content-type: multipart/signed" so the attacker knows at least one full block of plaintext as shown in (a). She can then form a canonical plaintext block whose content is all zeros as shown in (b). We call the block pair X and C0 a CBC gadget. In step (c), she then repeatedly appends CBC gadgets to inject an image tag into the encrypted plaintext. This creates a single encrypted body part that exfiltrates its own plaintext when the user opens the attacker email.
This is a little bit dense, but the idea behind the "exfiltration" is tricking the email client into decrypting a modified message that will have the original plaintext inside a URL inside an HTML img
tag, so that the email client will request that URL when the user opens the email. The attacker points that URL at their own servers, and monitors their access logs to learn the plaintexts.
I'll close with some informal remarks that might help you:
- Most classical cryptography existed in a world where there were no computers. Humans decrypted messages and interpreted their content using common sense.
- Modern cryptography exists in a world where computers are ubiquitous. Messages are decrypted by computers that blindly perform automated actions on the decrypted content.
Therefore, while classical cryptography often cared only about whether encryption provided confidentiality for messages, modern cryptography cares just as much about providing message authenticity—it's not enough that a passive eavesdropper be unable to learn anything new about the plaintext from its ciphertext, we also need to prevent an active attacker who has partial knowledge about the plaintext (e.g., the email format headers) from leveraging that to modify ciphertexts in ways that produce controllable changes in plaintext that the recipient (a computer, not a person!) will admit as authentic.
So the modern standard that encryption algorithms are expected to live up to is authenticated encryption. One-time pads guarantee perfect confidentiality, but don't guarantee message authenticity at all.
$endgroup$
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:38
1
$begingroup$
-1: I don't think this is a good example, as the EFAIL attack that is described above does not work with OTPs. Crucially, an attacker cannot create a new email that he sends to the victim, nor can he create additional canonical OTP blocks.
$endgroup$
– Fax
Feb 12 at 17:38
$begingroup$
I do have to agree with @Fax above. Although the EFAIL attack is a clear demonstration how unauthenticated messages can be attacked using active attacks (and it is therefore a good example what happens if you don't authenticate your messages) I don't see how this would work for an OTP.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:56
1
$begingroup$
I certainly do not claim EFAIL would work with an OTP, but I still think it's a good example of why ciphertext malleability is a serious problem that modern cryptography must guard again. The solution—make sure that all forged ciphertexts are rejected except with negligible probability—is insensitive to the details of which attacks work against which ciphers. And @Fax, I don't think your "crucial" part is actually crucial; using a forgery to trick the email client to reveal the plaintext more than bad enough already.
$endgroup$
– Luis Casillas
Feb 12 at 23:21
$begingroup$
@LuisCasillas Although you're comparing apples and oranges- OTP is symmetric and Public Key is asymmetric, I really like your approach trying to make an evidenced-based proof rather than relying on pure theoretical. And your answer inadvertently shed light on security issues with Public Key systems many might not have been aware of. So +1 for a scientific approach you took to your answer.
$endgroup$
– F1Linux
Feb 14 at 12:09
|
show 4 more comments
$begingroup$
One way to address this question is to give an example of a real-world attack that relies on being able to modify a ciphertext in a way that alters the resulting plaintext in a predictable, attacker-controllable manner. And there's a very notable example from last year: 2018's EFAIL attack on encrypted email clients:
The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
And further down, describing one of the variants of the attack, note the two sentences I've boldfaced:
Second, we describe the novel CBC/CFB gadget attacks which abuse vulnerabilities in the specification of OpenPGP and S/MIME to exfiltrate the plaintext. The diagram below describes the idea of CBC gadgets in S/MIME. Because of the specifics of the CBC mode of operation, an attacker can precisely modify plaintext blocks if she knows the plaintext. S/MIME encrypted emails usually start with "Content-type: multipart/signed" so the attacker knows at least one full block of plaintext as shown in (a). She can then form a canonical plaintext block whose content is all zeros as shown in (b). We call the block pair X and C0 a CBC gadget. In step (c), she then repeatedly appends CBC gadgets to inject an image tag into the encrypted plaintext. This creates a single encrypted body part that exfiltrates its own plaintext when the user opens the attacker email.
This is a little bit dense, but the idea behind the "exfiltration" is tricking the email client into decrypting a modified message that will have the original plaintext inside a URL inside an HTML img
tag, so that the email client will request that URL when the user opens the email. The attacker points that URL at their own servers, and monitors their access logs to learn the plaintexts.
I'll close with some informal remarks that might help you:
- Most classical cryptography existed in a world where there were no computers. Humans decrypted messages and interpreted their content using common sense.
- Modern cryptography exists in a world where computers are ubiquitous. Messages are decrypted by computers that blindly perform automated actions on the decrypted content.
Therefore, while classical cryptography often cared only about whether encryption provided confidentiality for messages, modern cryptography cares just as much about providing message authenticity—it's not enough that a passive eavesdropper be unable to learn anything new about the plaintext from its ciphertext, we also need to prevent an active attacker who has partial knowledge about the plaintext (e.g., the email format headers) from leveraging that to modify ciphertexts in ways that produce controllable changes in plaintext that the recipient (a computer, not a person!) will admit as authentic.
So the modern standard that encryption algorithms are expected to live up to is authenticated encryption. One-time pads guarantee perfect confidentiality, but don't guarantee message authenticity at all.
$endgroup$
One way to address this question is to give an example of a real-world attack that relies on being able to modify a ciphertext in a way that alters the resulting plaintext in a predictable, attacker-controllable manner. And there's a very notable example from last year: 2018's EFAIL attack on encrypted email clients:
The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
And further down, describing one of the variants of the attack, note the two sentences I've boldfaced:
Second, we describe the novel CBC/CFB gadget attacks which abuse vulnerabilities in the specification of OpenPGP and S/MIME to exfiltrate the plaintext. The diagram below describes the idea of CBC gadgets in S/MIME. Because of the specifics of the CBC mode of operation, an attacker can precisely modify plaintext blocks if she knows the plaintext. S/MIME encrypted emails usually start with "Content-type: multipart/signed" so the attacker knows at least one full block of plaintext as shown in (a). She can then form a canonical plaintext block whose content is all zeros as shown in (b). We call the block pair X and C0 a CBC gadget. In step (c), she then repeatedly appends CBC gadgets to inject an image tag into the encrypted plaintext. This creates a single encrypted body part that exfiltrates its own plaintext when the user opens the attacker email.
This is a little bit dense, but the idea behind the "exfiltration" is tricking the email client into decrypting a modified message that will have the original plaintext inside a URL inside an HTML img
tag, so that the email client will request that URL when the user opens the email. The attacker points that URL at their own servers, and monitors their access logs to learn the plaintexts.
I'll close with some informal remarks that might help you:
- Most classical cryptography existed in a world where there were no computers. Humans decrypted messages and interpreted their content using common sense.
- Modern cryptography exists in a world where computers are ubiquitous. Messages are decrypted by computers that blindly perform automated actions on the decrypted content.
Therefore, while classical cryptography often cared only about whether encryption provided confidentiality for messages, modern cryptography cares just as much about providing message authenticity—it's not enough that a passive eavesdropper be unable to learn anything new about the plaintext from its ciphertext, we also need to prevent an active attacker who has partial knowledge about the plaintext (e.g., the email format headers) from leveraging that to modify ciphertexts in ways that produce controllable changes in plaintext that the recipient (a computer, not a person!) will admit as authentic.
So the modern standard that encryption algorithms are expected to live up to is authenticated encryption. One-time pads guarantee perfect confidentiality, but don't guarantee message authenticity at all.
answered Feb 11 at 18:56
Luis CasillasLuis Casillas
9,91011438
9,91011438
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:38
1
$begingroup$
-1: I don't think this is a good example, as the EFAIL attack that is described above does not work with OTPs. Crucially, an attacker cannot create a new email that he sends to the victim, nor can he create additional canonical OTP blocks.
$endgroup$
– Fax
Feb 12 at 17:38
$begingroup$
I do have to agree with @Fax above. Although the EFAIL attack is a clear demonstration how unauthenticated messages can be attacked using active attacks (and it is therefore a good example what happens if you don't authenticate your messages) I don't see how this would work for an OTP.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:56
1
$begingroup$
I certainly do not claim EFAIL would work with an OTP, but I still think it's a good example of why ciphertext malleability is a serious problem that modern cryptography must guard again. The solution—make sure that all forged ciphertexts are rejected except with negligible probability—is insensitive to the details of which attacks work against which ciphers. And @Fax, I don't think your "crucial" part is actually crucial; using a forgery to trick the email client to reveal the plaintext more than bad enough already.
$endgroup$
– Luis Casillas
Feb 12 at 23:21
$begingroup$
@LuisCasillas Although you're comparing apples and oranges- OTP is symmetric and Public Key is asymmetric, I really like your approach trying to make an evidenced-based proof rather than relying on pure theoretical. And your answer inadvertently shed light on security issues with Public Key systems many might not have been aware of. So +1 for a scientific approach you took to your answer.
$endgroup$
– F1Linux
Feb 14 at 12:09
|
show 4 more comments
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:38
1
$begingroup$
-1: I don't think this is a good example, as the EFAIL attack that is described above does not work with OTPs. Crucially, an attacker cannot create a new email that he sends to the victim, nor can he create additional canonical OTP blocks.
$endgroup$
– Fax
Feb 12 at 17:38
$begingroup$
I do have to agree with @Fax above. Although the EFAIL attack is a clear demonstration how unauthenticated messages can be attacked using active attacks (and it is therefore a good example what happens if you don't authenticate your messages) I don't see how this would work for an OTP.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:56
1
$begingroup$
I certainly do not claim EFAIL would work with an OTP, but I still think it's a good example of why ciphertext malleability is a serious problem that modern cryptography must guard again. The solution—make sure that all forged ciphertexts are rejected except with negligible probability—is insensitive to the details of which attacks work against which ciphers. And @Fax, I don't think your "crucial" part is actually crucial; using a forgery to trick the email client to reveal the plaintext more than bad enough already.
$endgroup$
– Luis Casillas
Feb 12 at 23:21
$begingroup$
@LuisCasillas Although you're comparing apples and oranges- OTP is symmetric and Public Key is asymmetric, I really like your approach trying to make an evidenced-based proof rather than relying on pure theoretical. And your answer inadvertently shed light on security issues with Public Key systems many might not have been aware of. So +1 for a scientific approach you took to your answer.
$endgroup$
– F1Linux
Feb 14 at 12:09
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:38
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:38
1
1
$begingroup$
-1: I don't think this is a good example, as the EFAIL attack that is described above does not work with OTPs. Crucially, an attacker cannot create a new email that he sends to the victim, nor can he create additional canonical OTP blocks.
$endgroup$
– Fax
Feb 12 at 17:38
$begingroup$
-1: I don't think this is a good example, as the EFAIL attack that is described above does not work with OTPs. Crucially, an attacker cannot create a new email that he sends to the victim, nor can he create additional canonical OTP blocks.
$endgroup$
– Fax
Feb 12 at 17:38
$begingroup$
I do have to agree with @Fax above. Although the EFAIL attack is a clear demonstration how unauthenticated messages can be attacked using active attacks (and it is therefore a good example what happens if you don't authenticate your messages) I don't see how this would work for an OTP.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:56
$begingroup$
I do have to agree with @Fax above. Although the EFAIL attack is a clear demonstration how unauthenticated messages can be attacked using active attacks (and it is therefore a good example what happens if you don't authenticate your messages) I don't see how this would work for an OTP.
$endgroup$
– Maarten Bodewes♦
Feb 12 at 17:56
1
1
$begingroup$
I certainly do not claim EFAIL would work with an OTP, but I still think it's a good example of why ciphertext malleability is a serious problem that modern cryptography must guard again. The solution—make sure that all forged ciphertexts are rejected except with negligible probability—is insensitive to the details of which attacks work against which ciphers. And @Fax, I don't think your "crucial" part is actually crucial; using a forgery to trick the email client to reveal the plaintext more than bad enough already.
$endgroup$
– Luis Casillas
Feb 12 at 23:21
$begingroup$
I certainly do not claim EFAIL would work with an OTP, but I still think it's a good example of why ciphertext malleability is a serious problem that modern cryptography must guard again. The solution—make sure that all forged ciphertexts are rejected except with negligible probability—is insensitive to the details of which attacks work against which ciphers. And @Fax, I don't think your "crucial" part is actually crucial; using a forgery to trick the email client to reveal the plaintext more than bad enough already.
$endgroup$
– Luis Casillas
Feb 12 at 23:21
$begingroup$
@LuisCasillas Although you're comparing apples and oranges- OTP is symmetric and Public Key is asymmetric, I really like your approach trying to make an evidenced-based proof rather than relying on pure theoretical. And your answer inadvertently shed light on security issues with Public Key systems many might not have been aware of. So +1 for a scientific approach you took to your answer.
$endgroup$
– F1Linux
Feb 14 at 12:09
$begingroup$
@LuisCasillas Although you're comparing apples and oranges- OTP is symmetric and Public Key is asymmetric, I really like your approach trying to make an evidenced-based proof rather than relying on pure theoretical. And your answer inadvertently shed light on security issues with Public Key systems many might not have been aware of. So +1 for a scientific approach you took to your answer.
$endgroup$
– F1Linux
Feb 14 at 12:09
|
show 4 more comments
$begingroup$
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent.
The pillars of information security are confidentiality, integrity, and availability. (integrity and authenticity are sometimes used interchangeably).
Encryption is a tool for providing confidentiality. It does not by itself provide integrity.
Integrity is provided by a MAC, digital signature, or authenticated encryption scheme.
An adversaries ability to modify ciphertexts is a problem that is inherent to encryption schemes in general and is not specific to OTPs.
The question "Why should I use Authenticated Encryption instead of just encryption" covers this pretty thoroughly and fgrieu's answer provides another example.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to.
OTPs offer perfect secrecy, which means that given a ciphertext an adversary cannot learn anything more about the plaintext than they already knew. This last part is key: A OTP does not mean that an adversary knows nothing about the plaintext already, it means that they cannot use a ciphertext to learn more than they already knew.
The security models for confidentiality consider the following scenarios:
- Ciphertext only attack
- Known plaintext attack
- Chosen plaintext attack
- e.g. the adversary has access to an encryption oracle
- Chosen ciphertext attack
- e.g. the adversary has access to a decryption oracle
The ciphertext only attack model cannot in general be relied upon. Typically at least a known-plaintext attack model needs to be considered.
The reason for this is because messages are not (generally) strings of uniformly random bits. This means that the plaintext consists of less than 1 bit of entropy (uncertainty) per bit of message. This means that an adversary knows or can guess some of the contents of the message.
This is actually not as unreasonable as it may seem at first: Most real-world communications possess structure that is probably known to the adversary. For example, an HTTP request has certain fields that are always and/or commonly present, and the values of those fields are typically structured as well.
OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course.
This is a big "if". There are a lot of prerequisites, and it is easy to fail at them even when the stakes are very high.
The main problem that modern cryptographic techniques solve is not symmetric encryption to secure messages (which is relatively easy), but key management.
Key management for OTPs is maximumly difficult. For the modern world (e,g. the internet), it is prohibitively so.
This is why the apparently easy, fast, and obvious solution of using OTPs is not supported by modern protocols or standardized for use (unlike algorithms such as AES or Salsa20, which do have official standards and a specification).
The reason why people advocate against OTPs is not because they are insecure, but because they are practically unusable.
$endgroup$
$begingroup$
1TB HD, tamper detection seals, SATA locked, $100 I think OTP is usable now.
$endgroup$
– Joshua
Feb 11 at 23:35
1
$begingroup$
@Joshua For the most common use case of securing the internet, each web site would need to exchange (in person) keys with ever user. Assuming that they opted for a 1TB drive per user to minimize the number of required exchanges (and use the figure you quoted), a web site with only 10,000 users would need to spend $1,000,000 dollars to secure their connections. In reality, it would cost far more then $100 per user for secure redundant storage, and you could never do the key hand-off part to begin with in real life. There are many many reasons it is unusable other than the cost of storage.
$endgroup$
– Ella Rose♦
Feb 12 at 0:17
$begingroup$
Depends on who you are securing against. If against a state actor the internet is not secure now. Lavabit only stood because the government tried to make an example of them rather than use an NSA level attack. Getting a cert only requires demonstrating control of the domain (even before let's encrypt) and the feds could do that easily.
$endgroup$
– Joshua
Feb 12 at 14:29
add a comment |
$begingroup$
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent.
The pillars of information security are confidentiality, integrity, and availability. (integrity and authenticity are sometimes used interchangeably).
Encryption is a tool for providing confidentiality. It does not by itself provide integrity.
Integrity is provided by a MAC, digital signature, or authenticated encryption scheme.
An adversaries ability to modify ciphertexts is a problem that is inherent to encryption schemes in general and is not specific to OTPs.
The question "Why should I use Authenticated Encryption instead of just encryption" covers this pretty thoroughly and fgrieu's answer provides another example.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to.
OTPs offer perfect secrecy, which means that given a ciphertext an adversary cannot learn anything more about the plaintext than they already knew. This last part is key: A OTP does not mean that an adversary knows nothing about the plaintext already, it means that they cannot use a ciphertext to learn more than they already knew.
The security models for confidentiality consider the following scenarios:
- Ciphertext only attack
- Known plaintext attack
- Chosen plaintext attack
- e.g. the adversary has access to an encryption oracle
- Chosen ciphertext attack
- e.g. the adversary has access to a decryption oracle
The ciphertext only attack model cannot in general be relied upon. Typically at least a known-plaintext attack model needs to be considered.
The reason for this is because messages are not (generally) strings of uniformly random bits. This means that the plaintext consists of less than 1 bit of entropy (uncertainty) per bit of message. This means that an adversary knows or can guess some of the contents of the message.
This is actually not as unreasonable as it may seem at first: Most real-world communications possess structure that is probably known to the adversary. For example, an HTTP request has certain fields that are always and/or commonly present, and the values of those fields are typically structured as well.
OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course.
This is a big "if". There are a lot of prerequisites, and it is easy to fail at them even when the stakes are very high.
The main problem that modern cryptographic techniques solve is not symmetric encryption to secure messages (which is relatively easy), but key management.
Key management for OTPs is maximumly difficult. For the modern world (e,g. the internet), it is prohibitively so.
This is why the apparently easy, fast, and obvious solution of using OTPs is not supported by modern protocols or standardized for use (unlike algorithms such as AES or Salsa20, which do have official standards and a specification).
The reason why people advocate against OTPs is not because they are insecure, but because they are practically unusable.
$endgroup$
$begingroup$
1TB HD, tamper detection seals, SATA locked, $100 I think OTP is usable now.
$endgroup$
– Joshua
Feb 11 at 23:35
1
$begingroup$
@Joshua For the most common use case of securing the internet, each web site would need to exchange (in person) keys with ever user. Assuming that they opted for a 1TB drive per user to minimize the number of required exchanges (and use the figure you quoted), a web site with only 10,000 users would need to spend $1,000,000 dollars to secure their connections. In reality, it would cost far more then $100 per user for secure redundant storage, and you could never do the key hand-off part to begin with in real life. There are many many reasons it is unusable other than the cost of storage.
$endgroup$
– Ella Rose♦
Feb 12 at 0:17
$begingroup$
Depends on who you are securing against. If against a state actor the internet is not secure now. Lavabit only stood because the government tried to make an example of them rather than use an NSA level attack. Getting a cert only requires demonstrating control of the domain (even before let's encrypt) and the feds could do that easily.
$endgroup$
– Joshua
Feb 12 at 14:29
add a comment |
$begingroup$
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent.
The pillars of information security are confidentiality, integrity, and availability. (integrity and authenticity are sometimes used interchangeably).
Encryption is a tool for providing confidentiality. It does not by itself provide integrity.
Integrity is provided by a MAC, digital signature, or authenticated encryption scheme.
An adversaries ability to modify ciphertexts is a problem that is inherent to encryption schemes in general and is not specific to OTPs.
The question "Why should I use Authenticated Encryption instead of just encryption" covers this pretty thoroughly and fgrieu's answer provides another example.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to.
OTPs offer perfect secrecy, which means that given a ciphertext an adversary cannot learn anything more about the plaintext than they already knew. This last part is key: A OTP does not mean that an adversary knows nothing about the plaintext already, it means that they cannot use a ciphertext to learn more than they already knew.
The security models for confidentiality consider the following scenarios:
- Ciphertext only attack
- Known plaintext attack
- Chosen plaintext attack
- e.g. the adversary has access to an encryption oracle
- Chosen ciphertext attack
- e.g. the adversary has access to a decryption oracle
The ciphertext only attack model cannot in general be relied upon. Typically at least a known-plaintext attack model needs to be considered.
The reason for this is because messages are not (generally) strings of uniformly random bits. This means that the plaintext consists of less than 1 bit of entropy (uncertainty) per bit of message. This means that an adversary knows or can guess some of the contents of the message.
This is actually not as unreasonable as it may seem at first: Most real-world communications possess structure that is probably known to the adversary. For example, an HTTP request has certain fields that are always and/or commonly present, and the values of those fields are typically structured as well.
OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course.
This is a big "if". There are a lot of prerequisites, and it is easy to fail at them even when the stakes are very high.
The main problem that modern cryptographic techniques solve is not symmetric encryption to secure messages (which is relatively easy), but key management.
Key management for OTPs is maximumly difficult. For the modern world (e,g. the internet), it is prohibitively so.
This is why the apparently easy, fast, and obvious solution of using OTPs is not supported by modern protocols or standardized for use (unlike algorithms such as AES or Salsa20, which do have official standards and a specification).
The reason why people advocate against OTPs is not because they are insecure, but because they are practically unusable.
$endgroup$
"Bit Flip" in the context of these claims being that the OTP message can be tampered with in transit- that there's no validation the recipient has received exactly the message that was originally sent.
The pillars of information security are confidentiality, integrity, and availability. (integrity and authenticity are sometimes used interchangeably).
Encryption is a tool for providing confidentiality. It does not by itself provide integrity.
Integrity is provided by a MAC, digital signature, or authenticated encryption scheme.
An adversaries ability to modify ciphertexts is a problem that is inherent to encryption schemes in general and is not specific to OTPs.
The question "Why should I use Authenticated Encryption instead of just encryption" covers this pretty thoroughly and fgrieu's answer provides another example.
Further, in order to tamper with the contents of the OTP encrypted message would imply that the attacker knew exactly "when", "where", "how" and most importantly "who" the message was being transmitted to.
OTPs offer perfect secrecy, which means that given a ciphertext an adversary cannot learn anything more about the plaintext than they already knew. This last part is key: A OTP does not mean that an adversary knows nothing about the plaintext already, it means that they cannot use a ciphertext to learn more than they already knew.
The security models for confidentiality consider the following scenarios:
- Ciphertext only attack
- Known plaintext attack
- Chosen plaintext attack
- e.g. the adversary has access to an encryption oracle
- Chosen ciphertext attack
- e.g. the adversary has access to a decryption oracle
The ciphertext only attack model cannot in general be relied upon. Typically at least a known-plaintext attack model needs to be considered.
The reason for this is because messages are not (generally) strings of uniformly random bits. This means that the plaintext consists of less than 1 bit of entropy (uncertainty) per bit of message. This means that an adversary knows or can guess some of the contents of the message.
This is actually not as unreasonable as it may seem at first: Most real-world communications possess structure that is probably known to the adversary. For example, an HTTP request has certain fields that are always and/or commonly present, and the values of those fields are typically structured as well.
OTP encrypted messages are secure & unbreakable- if the system is operated correctly of course.
This is a big "if". There are a lot of prerequisites, and it is easy to fail at them even when the stakes are very high.
The main problem that modern cryptographic techniques solve is not symmetric encryption to secure messages (which is relatively easy), but key management.
Key management for OTPs is maximumly difficult. For the modern world (e,g. the internet), it is prohibitively so.
This is why the apparently easy, fast, and obvious solution of using OTPs is not supported by modern protocols or standardized for use (unlike algorithms such as AES or Salsa20, which do have official standards and a specification).
The reason why people advocate against OTPs is not because they are insecure, but because they are practically unusable.
edited Feb 11 at 18:27
answered Feb 11 at 18:16
Ella Rose♦Ella Rose
16.4k44281
16.4k44281
$begingroup$
1TB HD, tamper detection seals, SATA locked, $100 I think OTP is usable now.
$endgroup$
– Joshua
Feb 11 at 23:35
1
$begingroup$
@Joshua For the most common use case of securing the internet, each web site would need to exchange (in person) keys with ever user. Assuming that they opted for a 1TB drive per user to minimize the number of required exchanges (and use the figure you quoted), a web site with only 10,000 users would need to spend $1,000,000 dollars to secure their connections. In reality, it would cost far more then $100 per user for secure redundant storage, and you could never do the key hand-off part to begin with in real life. There are many many reasons it is unusable other than the cost of storage.
$endgroup$
– Ella Rose♦
Feb 12 at 0:17
$begingroup$
Depends on who you are securing against. If against a state actor the internet is not secure now. Lavabit only stood because the government tried to make an example of them rather than use an NSA level attack. Getting a cert only requires demonstrating control of the domain (even before let's encrypt) and the feds could do that easily.
$endgroup$
– Joshua
Feb 12 at 14:29
add a comment |
$begingroup$
1TB HD, tamper detection seals, SATA locked, $100 I think OTP is usable now.
$endgroup$
– Joshua
Feb 11 at 23:35
1
$begingroup$
@Joshua For the most common use case of securing the internet, each web site would need to exchange (in person) keys with ever user. Assuming that they opted for a 1TB drive per user to minimize the number of required exchanges (and use the figure you quoted), a web site with only 10,000 users would need to spend $1,000,000 dollars to secure their connections. In reality, it would cost far more then $100 per user for secure redundant storage, and you could never do the key hand-off part to begin with in real life. There are many many reasons it is unusable other than the cost of storage.
$endgroup$
– Ella Rose♦
Feb 12 at 0:17
$begingroup$
Depends on who you are securing against. If against a state actor the internet is not secure now. Lavabit only stood because the government tried to make an example of them rather than use an NSA level attack. Getting a cert only requires demonstrating control of the domain (even before let's encrypt) and the feds could do that easily.
$endgroup$
– Joshua
Feb 12 at 14:29
$begingroup$
1TB HD, tamper detection seals, SATA locked, $100 I think OTP is usable now.
$endgroup$
– Joshua
Feb 11 at 23:35
$begingroup$
1TB HD, tamper detection seals, SATA locked, $100 I think OTP is usable now.
$endgroup$
– Joshua
Feb 11 at 23:35
1
1
$begingroup$
@Joshua For the most common use case of securing the internet, each web site would need to exchange (in person) keys with ever user. Assuming that they opted for a 1TB drive per user to minimize the number of required exchanges (and use the figure you quoted), a web site with only 10,000 users would need to spend $1,000,000 dollars to secure their connections. In reality, it would cost far more then $100 per user for secure redundant storage, and you could never do the key hand-off part to begin with in real life. There are many many reasons it is unusable other than the cost of storage.
$endgroup$
– Ella Rose♦
Feb 12 at 0:17
$begingroup$
@Joshua For the most common use case of securing the internet, each web site would need to exchange (in person) keys with ever user. Assuming that they opted for a 1TB drive per user to minimize the number of required exchanges (and use the figure you quoted), a web site with only 10,000 users would need to spend $1,000,000 dollars to secure their connections. In reality, it would cost far more then $100 per user for secure redundant storage, and you could never do the key hand-off part to begin with in real life. There are many many reasons it is unusable other than the cost of storage.
$endgroup$
– Ella Rose♦
Feb 12 at 0:17
$begingroup$
Depends on who you are securing against. If against a state actor the internet is not secure now. Lavabit only stood because the government tried to make an example of them rather than use an NSA level attack. Getting a cert only requires demonstrating control of the domain (even before let's encrypt) and the feds could do that easily.
$endgroup$
– Joshua
Feb 12 at 14:29
$begingroup$
Depends on who you are securing against. If against a state actor the internet is not secure now. Lavabit only stood because the government tried to make an example of them rather than use an NSA level attack. Getting a cert only requires demonstrating control of the domain (even before let's encrypt) and the feds could do that easily.
$endgroup$
– Joshua
Feb 12 at 14:29
add a comment |
Thanks for contributing an answer to Cryptography Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcrypto.stackexchange.com%2fquestions%2f67233%2fone-time-pads-and-bit-flip-attacks%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
$begingroup$
Comments are not for extended discussion; this conversation has been moved to chat.
$endgroup$
– SEJPM♦
Feb 11 at 18:21
$begingroup$
I am perplexed; the answer should be polynomial mac but it's been blasted off wikipeida.
$endgroup$
– Joshua
Feb 11 at 23:26