1
$\begingroup$

I have some confusion that concerns the message digest.

I know that the message digest is the real message hashed with function and we use it to verify the integrity of the message.

I understand the usefulness of using this with asymmetric encryption but I can't find the utility of this with symmetric encryption.

I will explain my self:

We have Alice and Bob. Alice wants to transmit a message m to bob with symmetric encryption. Suppose that the two of them know the encryption key in advance.

Alice encrypts m with the key, hashes the message as hash(m) and sends it to Bob as (encrypt(m), hash(m)).

Bob decrypts the message and then hashed to verify the integrity.

In this case I think that the hash(message) is not needed because:

Case 1: If someone doesn't have the key they cannot cipher a message and send it to Bob pretending to be Alice because Bob will know that the message wasn't encrypted using the key. (We didn't use the hash message in this case).

Case 2: If someone has the key, they intercept the message of Alice and modify it to m2 then they encrypt and hash the new message and send it as (encrypt(m2),hash(m2)). When bob tries to verify the integrity of the message, the process will succeed (in this case using the hash didn't help to check the integrity of the message).

So in both cases the hashed message is not (or cannot) be used to check the integrity of the message.

Is this correct? Because I have argued with my teacher and he said that hashing the message helps to check for integrity in both symmetric and asymmetric encryption.

Is there some cases that hashing the message is useful?

$\endgroup$
2
$\begingroup$

Normally a message authentication code (MAC, for instance HMAC) is used for symmetric integrity and authenticity of the message. In that case a hash can be used with a secret key to protect the message; this is also called a keyed hash. Nowadays authenticated modes of encryption is also used a lot; for example an AEAD cipher such as GCM. AEAD ciphers combine message authentication code with encryption.

Sending encrypt(M) followed by hash(M) is certainly not secure, as the hash leaks information about M. If the message is "Yes" or "No!" then an attacker cannot distinguish between the two when CPA secure encryption is used. However, an attacker can simply test both possibilities by recalculating the hash over the message.

A hash over ciphertext send with the message isn't useful at all, as it would enable the attacker to simply change the ciphertext and then recalculate the hash. Before the hash was sometimes put over the plaintext as well and then encrypted, but that is still not as secure as performing a MAC over the ciphertext, and it may still allow for changing the ciphertext, allowing for instance padding oracle attacks.

With all that said, a hash can be used to secure the integrity / authenticity of a message, be it plaintext or ciphertext. In that case the hash itself must however be trusted. This can for instance be accomplished by putting the hash on a secured website, say apache.org. In that case messages (in this case applications) can be downloaded from mirrors and then compared to the hash, published on apache.org (hopefully over TLS, adding an additional layer of security).

With asymmetric encryption the hash can be trusted because it is verified that the hash was used together with the private key to generate the signature.

$\endgroup$
2
$\begingroup$

First, there is a serious confidentiality problem with:

Alice cipher the M with the key and hash the message hash(M) and send to bob (encrypted(M), hash(M))

The problem is that a guess of M can be checked, because the adversary can hash the guess and compare it to hash(M) which is assumed a given. If M is a name on the class roll, poof goes confidentiality.

That's why we use MAC(K, encrypted(M)) where K is a symmetric key (distinct from that used in "encrypted"), rather than hash(M). Strictly speaking, using MAC(K,M) does not work from a confidentiality standpoint, because it allows an adversary to distinguish identical M sent twice.


Further, with (encrypted(M), hash(M)) , if the adversary guesses M correctly, and encrypted(M) uses a malleable cipher (like AES-256 in CTR mode), the adversary can change M to any different M' (not larger than M), adjust encrypted(M) accordingly, and replace hash(M) with hash(M'); we do not have message integrity.

Notice that changing to sending (encrypted(M, hash(M)) only partially improve things; the adversary can no longer check a guess of M, but if s/he does get to know M then s/he can adjust the ciphertext to change M to M' and hash(M) to hash(M'); we still do not have message integrity.


Morality: authenticated encryption is tricky. We can't use (encrypted(M), hash(M)) , nor (encrypted(M, hash(M)) , nor (encrypted(M), MAC(K,M)), for a general definition of "encrypted", including perfectly good ones for the standpoint of confidentiality.

One thing that works is encrypted(M, MAC(K, encrypted(M)) with the key K of the MAC different from that used for "encrypted".

$\endgroup$
0
$\begingroup$

case 1: If someone doesn't have the key he cannot cipher a message and send it to bob pretending to be alice because bob will know that the message didn't get encryptage using the key. (we didn't use the hash message in this case).

I think you're coming at this from an "english" point of view, in many systems "people" aren't necessarily personally looking at encrypted messages. Sure you could immediately tell if some english text weren't decrypted property, but what if we're not talking about a message of english words? You can cipher a message with a key, and then decrypt a cipher text with a different key, it just won't be the intended message.

Another case - what if some bits get flipped in transfer of either the cipherText, or the digest? If either cipherText or digest is modified in any way, be it malicious or not (assuming the actual key isn't used), running a hash on the decrypted message and comparing to the original message will tell you that something is amiss, because it won't match the specified hash.

Have you looked at all into authenticated symmetric ciphers? AES-GCM, CMAC, AES-CCM as examples? These modes have a MAC/Tag sent along with the payload, which when decrypted and verified help ensure the message's authenticity.

$\endgroup$

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.