One-Time Pad authentication & Information-theoretic security

I'm trying to create a "Information Theoretically Secure" cryptosystem, inspired on the One-Time Pad.
Now I'm facing the obstacle of authentication...

How good is this solution (that uses the "Encrypt than MAC" method)? And can this benefit of the "Information Theoretic Security" provided by the OTP?

``````|| = concatenation

OTPKey = (OTPKeyPartForThePlaintext || OTPKeyPartForTheDigest)
ciphertext = (plaintext XOR OTPKeyPartForThePlaintext)
digest = sha256(OTPKey || ciphertext)
encryptedDigest = (digest XOR OTPKeyPartForTheDigest)
message = (ciphertext || encryptedDigest)
``````

Thank you :)

• Am I correct in assuming || is concatenation? As it is most often used as OR operation. Commented Oct 28, 2015 at 12:23
• Yes, with || I mean the concatenation. I've edited the question now :) Commented Oct 28, 2015 at 12:27
• Is the key generated to the standards of OTP keys? In particular, is the key truly random? (For anything less than truly random, your scheme would seem to allow an attacker to determine if a given decryption is likely to be the correct one.)
– user
Commented Oct 28, 2015 at 12:35
• Yes, let's assume that the keys are truly random, generated by a hardware random number generator. Commented Oct 28, 2015 at 12:39
• I've been thinking about this and can't seem to find a good reason to add the OTPKey in the sha calculation. What is your reason for this? Commented Oct 28, 2015 at 19:02

MAC intends to offer integrity and authenticity.

However using a OTP one does not need authenticity as you know only you and the other party have the OTP key. This is only needed for public key encryption where everyone can encrypt a message that only you can decrypt. Thus in that case you need authenticity but for symmetric encryption there is no need for authenticity and thus not for MAC.

You still need integrity of course but in this case the following makes more sense:

message = ciphertext = ( plaintext || sha256(plaintext) ) XOR OTPKey

When using a OTP there is no downside to using this method as the structure created in the plaintext + sha of plaintext cannot be exploited when using OTP's.

• Thank you for the answer :) I've already thought about this solution but I think it is vulnerable to known-plaintext attacks... If the plaintext is known, Mallory can hash it and obtain the digest. With (plaintext || digest) he can obtain the whole OTPKey and send to Bob the message he wants. Commented Oct 29, 2015 at 9:37
• The solution I wrote in my question I think is less vulnerable to this attack because even if Mallory knows the plaintext, he also knows the message, the ciphertext and the OTPKeyPartForThePlaintext, but not the OTPKeyPartForTheDigest. So if he wants to obtain the entire OTPKey he must try all the possible key combinations (32bytes of OTPKeyPartForTheDigest), in total 2^256. Is this right? Commented Oct 29, 2015 at 10:05
• @RiccardoLeschiutta when you are using a OTP what is the point of preventing known plain text attacks? To get the password ..., no as that changes for every message. To decrypt the rest of the ciphertext when a partial message is known ..., no as there is no structure introduced in a OTP encryption, knowing A of a AB plaintext can't help you know anything about B. This is part of the reason why a OTP is completely secure from a theoretical standpoint. Commented Oct 29, 2015 at 10:22
• Thank you, so with ciphertext = ( plaintext || sha256(plaintext) ) XOR OTPKey can I be sure that an attacker can't obtain the plaintext exploiting possible vulnerabilities introduced by the use of sha256? Commented Dec 5, 2015 at 20:15

Author is correct:

I've already thought about this solution but I think it is vulnerable to known-plaintext attacks... If the plaintext is known, Mallory can hash it and obtain the digest. With (plaintext || digest) he can obtain the whole OTPKey and send to Bob the message he wants.

If Alice sends:

``````{plaintext} {sha256 of plaintext}
XOR {OTP keystream}
``````

Mallory can intercept this and (knowing the plaintext) calculate

`````` {ciphertext}
XOR {plaintext} {sha256 of plaintext}
``````

in order to obtain {OTP keystream}, which allows them to calculate:

`````` {modified evil message} {sha256 of modified evil message}
XOR {OTP keystream}
``````

and replace the message with this crafted one.

See the answer to this question: Unconditionally Secure Authentication