1

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

Riccardo Leschiutta
  • 199
  • 6
  • 1
    Am I correct in assuming || is concatenation? As it is most often used as OR operation. – Selenog Oct 28 '15 at 12:23
  • Yes, with || I mean the concatenation. I've edited the question now :) – Riccardo Leschiutta Oct 28 '15 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 Oct 28 '15 at 12:35
  • Yes, let's assume that the keys are truly random, generated by a hardware random number generator. – Riccardo Leschiutta Oct 28 '15 at 12:39
  • 1
    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? – Selenog Oct 28 '15 at 19:02
  • Because I think that if the digest is calculated with sha256(ciphertext) only, an attacker can calculate the digest himself, XOR it with the encryptedDigest and obtain the OTPKeyPartForTheDigest. With that part he can replace the ciphertext with one he choose, calculate the digest and encrypt it with the key and the message will seem authentic. Is my reasoning correct? :) – Riccardo Leschiutta Oct 28 '15 at 19:19
  • @RiccardoLeschiutta I see your reasoning now, failed to notice you want MAC. What you are actualy doing is encrypt then mac then encrypt again. – Selenog Oct 29 '15 at 07:28

2 Answers2

1

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

Community
  • 1
Anonymousse
  • 11
  • 1
-1

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.

Selenog
  • 984
  • 4
  • 8
  • 1
    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. – Riccardo Leschiutta Oct 29 '15 at 09: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? – Riccardo Leschiutta Oct 29 '15 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. – Selenog Oct 29 '15 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? – Riccardo Leschiutta Dec 05 '15 at 20:15