2

I'm trying to add the authentication for my One-Time Pad implementation.
I know that to provide Unconditionally Secure Authentication I need to use the One-Time MAC authentication.

But I don't understand why a solution as the following (that's a lot more easy to implement) doesn't provide the same security level :/

ciphertext = ((plaintext || H(plaintext)) XOR OTPKey)

With:
|| = concatenation
H = SHA-2
OTPKey is long enough to encrypt the plaintext and H(plaintext)

Mallory here can't brute force the ciphertext (because of the one-time pad), so he can't get the correct plaintext nor the digest...

Is this right? Can this provide unconditionally secure authentication?

EDIT 1
I know that in practice it's vulnerable to known-plaintext attacks so please, don't consider it in this particular case. I'm interested in Unconditional Security in the sense that both the plaintext and the digest can benefit of the Information-theoretic security provided by One-Time Pad.
I'm interested in passive attacks and not in active ones.
Assume that Mallory here knows only the ciphertext ;-)

EDIT 2
In other words: can I be sure that an attacker can't obtain the plaintext exploiting possible vulnerabilities introduced by the use of a hash function for the digest calculation?

Variant
How about this variant? Can I say that it provides Information-theoretic security for the plaintext AND it is vulnerable against active attacks with complexity of 2^256?
So in this case I can provide a certain level of security against known-plaintext attacks too (even if computational security).

ciphertext = (plaintext XOR OTPKey)
message = (ciphertext || H(ciphertext || K2))

With:
K2 = 32 bytes of random key, NOT correlated with OTPKey

Thank you to everyone :)

  • Do I understand correctly that you are looking for a MAC that will not leak information about the plain text, even in the face of an unbounded attacker (simple: EtA will work)? – Henrick Hellström Dec 05 '15 at 16:21
  • @HenrickHellström I'm trying to understand if the solution I wrote on my question guarantees that an attacker with infinite computational power can't get access to the plaintext nor to the H(plaintext). So both the plaintext and the digest can benefit of the Information-theoretic security provided by OTP. If this is correct, I can guarantee the integrity of the plaintext and its authentication. Additionally I can be sure that an attacker can't get the plaintext, exploiting vulnerabilities introduced by the use of a hash function for the digest calculation. – Riccardo Leschiutta Dec 05 '15 at 16:55
  • Is your EDIT 2 question still restricting to passive attacks? ​ ​ –  Dec 05 '15 at 17:20
  • @RickyDemer Yes, for the moment :) – Riccardo Leschiutta Dec 05 '15 at 17:24
  • In that case: ​ ​ ​ Yes. ​ length(H(plaintext)) only depends on length(plaintext) so length(plaintext || H(plaintext) also only depends on length(plaintext). ​ ​ ​ ​ ​ ​ ​ ​ –  Dec 05 '15 at 17:32
  • @RickyDemer What the length has to do with my question? In addition, SHA-2 produces a fixed-length output, length(H(plaintext)) does not depends on length(plaintext) :/ – Riccardo Leschiutta Dec 05 '15 at 19:17
  • Length has to do with this question due to the OTP hiding everything else from eavesdroppers. ​ Oh yes, so the conclusion in fact holds for an even easier reason than I was trying to use. ​ ​ ​ ​ –  Dec 05 '15 at 19:21
  • 1
    crossposted to security without mentioning that on either site ​ ​ –  Dec 05 '15 at 19:31

1 Answers1

3

You need to prove that there does not exist a way of finding $x$ and $y$ so that $plaintext \oplus x$ and $H(plaintext) \oplus y = H(plaintext \oplus x)$. The problem is that the attacker is unlimited in time, so the above may actually be possible. (It suffices to prove that there exist messages for which this can be done.)

In addition, in order for this to be secure, it has to behave as a secure MAC, even known the plaintext. So, saying that you don't care about known-plaintext attacks doesn't make sense. I'll explain. Assume that the distribution over the plaintext is that with probability $0.7$ the plaintext is "attack today" and with probability $0.3$ it is "don't attack". Then, an attacker can assume that the message is "attack today" and modify it to "don't attack" (by XORing in "attack today XOR don't attack" to the first part, and XORing in "H(attack today) XOR H(don't attack)" in the second part. The result will be that with probability $0.7$ the message will be changed to "don't attack" and with probability $0.3$ an invalid message will be received. This should not be allowed under any reasonable definition of security.

Yehuda Lindell
  • 27,820
  • 1
  • 66
  • 83
  • Thank you for the answer :) How can an attacker know which of the possible plaintext is the correct one? With OTP, brute force is not possible because trying all the possible keys he gets all the possible plaintext, all equally probable. As I wrote in my question, I know it is vulnerable to known-plaintext attacks. It is a starting point for my thesis, to demonstrate that could be more secure add a key to the MAC calculation instead of the use of a hash function without key and than encrypt with OTP. I update my question. Do you think it's reasonable? – Riccardo Leschiutta Dec 06 '15 at 07:30
  • The attacker doesn't need to know which is the correct plaintext. It just needs to change the probabilities. If it's a completely random plaintext, then this changes the question (so I think it should be changed back since now the answer doesn't fit). But it's a very weak notion of security and one that is not meaningful. In particular, if you encrypt something with that key, then it already won't be a strong enough definition. – Yehuda Lindell Dec 06 '15 at 16:33