-1

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?

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 ;-)

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 :)

  • 1
    crossposted from crypto without mentioning that on either site ​ ​ – user49075 Dec 5 '15 at 19:31
  • @RickyDemer Is this not allowed? I am the same person who wrote in both forums, I hope you haven't down-vote my question for this reason :/ – Riccardo Leschiutta Dec 5 '15 at 19:42
  • Yes, 5 hours is much too soon. ​ If I wasn't fairly confident that the OPs were the same person, then I wouldn't have down-voted. ​ (Note that users can't down-vote the same question twice, so someone else also down-voted.) ​ ​ ​ ​ – user49075 Dec 5 '15 at 19:59
  • You can also say that "it is vulnerable against active attacks with complexity of" 2^1234. ​ (i.e., there are much faster active attacks.) ​ ​ ​ ​ – user49075 Dec 6 '15 at 1:21
  • @RickyDemer "You can also say that "it is vulnerable against active attacks with complexity of" 2^1234. ​ (i.e., there are much faster active attacks.)" has ho sense to me because 2^1234 is not faster than a brute-force with complexity of 2^256. If you know to break it with lower complexity please explain. – Riccardo Leschiutta Dec 6 '15 at 7:18
1

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?

I think you're safe. I think the only issue might be with the OTPKey implementation. You can't re-use the same key twice, it has to be truly random, and the key itself must be secure and known to both parties. Also, the contents of the message have to be completely unpredictable otherwise the key will be theoretically vulnerable to brute-force attack methods. Because of this, I would additionally implement a random value at the beginning of the message to be XORd with the rest of the message before anything. Other than that, I say all engines go.

Update

Regarding this method:

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

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

This should be effective as long as the attacker cannot get ahold of K2

  • Thank you very much :) I've also edited my question and I've added a variant solution. Can you tell me if my reasoning is correct? – Riccardo Leschiutta Dec 5 '15 at 21:18
  • 1
    @RiccardoLeschiutta Looks good to me, just keep K2 nice and safe :) – Jonathan Gray Dec 5 '15 at 21:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.