4

I was reading the chosen answer to the following question -

"MAC vs Encryption"

They say that just using encryption, "an attacker could alter the ciphertext to make it say something else when decrypted", and then say by hashing the message, adding onto the end and encrypting the entire thing, this provides integrity.

My question is, if the attacker can alter the ciphertext even when it's encyrpted, can't the attacker also alter the hash attached to the end of the message so that it matches the modified text?

Thanks in advance.

Improve this question

3 Answers 3

Reset to default
3

The attacker can modify certain bits of the plaintext (by modifying the ciphertext), but the attacker does not know what the entire plaintext originally was. Therefore, the attacker doesn't know what bits of the hash will change due to their alterations of the plaintext. To successfully modify the hash and the plaintext, the attacker would need to know the difference between the original hash and the hash of the modified plaintext. The attacker doesn't know this difference, which prevents the attacker from changing the hash to match the modified plaintext.

Now, all of this is based on the idea that the recipient is supposed to decrypt the data, then verify its authenticity. While this can be done, it's also possible to protect the integrity of the ciphertext, allowing the recipient to verify that the message hasn't been tampered with before even attempting decryption. Obviously, just hashing the ciphertext and appending it to the end doesn't work, because the attacker could modify that hash. Instead, there are two ways of doing this, based on the kind of crypto in use. They are both hash-based but have extra security beyond simply hashing:

  • If using asymmetric cryptography, such as the usual way to use HTTPS or SSH, then you digitally sign the hash. Without getting into the mathematics of how digital signature schemes work, the basic idea is that you have two keys: a private key that only you know, and a public key that everybody can get a copy of. The private key is used to sign the hash, and the public key is used to verify the signature. Because the attacker doesn't have your private key, if they modify the message and re-compute the hash, they won't be able to re-create a signature that can be verified using your public key. Therefore, anybody will be able to use your public key to tell that the message they received is not the message that you signed.
  • If using symmetric cryptography only, like an encrypted .ZIP file or most other forms of password encryption, you create a keyed Hash-based Message Authentication Code (or HMAC). Again, without going into the details, the idea of an HMAC is that when you compute the hash of the message, you also stick in some additional data that is based on a key (which might be the key used to encrypt the message, or might be another one) that the intended recipient of the encrypted message also has. This additional data added to the hash function input modifies the output (the digest) in such a way that if an attacker modifies the message, the attacker won't be able to figure out what the new HMAC should be because the attacker doesn't know the key and therefore, when the recipient uses the key to compute the HMAC of the modified message, it won't match and the recipient will know the message was tampered with.
Improve this answer
12
  • 1
    The attacker only knows part of the modified plaintext. Manipulating ciphertext doesn't set plaintext to a desired value; it flips bits in the plaintext. In order to change the entire plaintext, you would need to know the entire original plaintext in order to know which bits to flip to reach your desired outcome. If you know the original plaintext, you've already defeated the confidentiality that encryption is supposed to provide. So no, the attacker doesn't know what the (whole) new plaintext will be, nor what the original hast was, so they can't update the hash accurately.
    – CBHacking
    Commented Oct 18, 2015 at 8:28
  • 1
    Often, the attacker knows part of the plaintext but not all of it. For example, in HTTPS traffic, an attacker might not actually know the authentication cookie, but (if they know the URL) they probably know the headers up to the Cookie: part, just not what comes next. Blindly garbling encrypted data is certainly possible (if you don't have a MAC protecting the ciphertext) but usually when this is a threat, it's because the attacker is specifically trying to change a bit of data that they know about to some other value.
    – CBHacking
    Commented Oct 21, 2015 at 20:34
  • 1
    That last question is worth doing some research on - semi-blind modification of plaintext by manipulating ciphertext is not new - but I can summarize it a bit. To take the example of HTTPS (assuming TLS didn't have integrity checks, which it does have), if I know somebody has requested example.org but not what value their session cookie has, I know that the first part of their request will look like GET / HTTP/1.1\r\nHost: example.org\r\n...\r\nCookie: session= but not the actual cookie value. I could change the Host header to something else by flipping bits, though.
    – CBHacking
    Commented Oct 22, 2015 at 11:31
  • 1
    Doing so may corrupt the rest of the message (depending on the cipher; in a stream cipher like RC4 you can usually alter bits without preventing the rest for decrypting correctly), and I could never learn what the original session cookie value was. However, if I took some of the less-critical headers whose values I could predict (like the user-agent string, which varies by browser but is one of a few options) and turn it into a Cookie header, then terminate the headers with \r\n\r\n. The server gets a strangely short request with some garbage after it, but with a cookie value I control.
    – CBHacking
    Commented Oct 22, 2015 at 11:36
  • 1
    Assuming a stream cipher (like RC4, which really shouldn't be used anymore for TLS but for reasons not related to this problem), producing the modifications is easy. Start with the plaintext that you will modify (you must know every byte of this plaintext, and its offset from the message start). XOR the to-modify text with the new value you want to change it into. This produces the bitwise difference between the texts. XOR that into the ciphertext at the correct offset. When decrypted , the bits you flipped (via XOR) in the ciphertext will be flipped in the plaintext, changing the message.
    – CBHacking
    Commented Oct 22, 2015 at 17:50
2

Maybe a not-so-technical view helps understanding the problem... Just think of an envelope that contains the message and the hashsum. You can punch the envelope and flip certain bits of the message. You can also punch where the hashsum is and change bits of it. However, as you cannot look inside the envelope you have (almost) no chance to flip the hashsum in a way that yields the correct value for the modified message.

When the receiver opens the envelope they see a message and a hashsum that do not match - a clear indication that something was modified, the message, the checksum or both.

Edit:

Ok, more technical... :-)

Consider the following message M, which I transfer plain-text.

Please transfer 100$ to my account.

its (SHA1) hashsum is 5f7e22d270ca9da68543e3f97f30f1859e20a88a. The resulting MAC is

f56c10e4264a5173aa97660f7438fc0e12618d1e

This MAC is the hashsum that I encrypted with a secret password. You can freely modify the message and the MAC, but you cannot figure out how to modify the MAC so that, when I decrypt it, it delivers the correct hashsum, that matches your modified message. Consequently when I decrypt, I will notice that the hashsum does not match the message and something was modified.

That is what a MAC is all about, detecting modifications.

Improve this answer
5
  • Thanks @fr00tyl00p, the analogy you used is how I initially understood it, but the part about being able to modify the ciphertext has me confused. I understand an attacker can randomly flip bits and therefore the hash and original text won't match when decrypted, but their answer seemed to suggest an attacker could modify the ciphertext to something they choose? or have I misunderstood. If an attacker can only randomly flip bits in the ciphertext to ruin the integrity of the message then that makes sense.
    – RJSmith92
    Commented Oct 18, 2015 at 13:33
  • Sorry to bother you @fr00tyl00p can you just confirm something for me? When the attacker 'punches the envelope' do they have any idea of 'what' they have flipped or 'what' they have flipped it to? or can they just flip bits of the ciphertext at random without knowing what they have changed and what it will be changed to?
    – RJSmith92
    Commented Oct 20, 2015 at 12:02
  • 1
    You can change the ciphertext to anything you want. But you (usually) cannot know what the cleartext after decryption will be then. This holds for both the message and the hashsum.
    – fr00tyl00p
    Commented Oct 20, 2015 at 12:25
  • Thanks @fr00tyl00p. I was being an idiot, I thought when they said 'an attacker could alter the ciphertext to make it say something else when decrypted', they knew what they were changing. For example they could edit the ciphertext so it said 1000$ instead of 100$, then could change the encrypted hash to match the new text, but if they could do all that it would completely defeat the purpose of encrypting the plain text in the first place. So am I right in thinking the only thing an attacker can do with ciphertext is randomly change it to produce gibberish once decrypted?
    – RJSmith92
    Commented Oct 20, 2015 at 14:15
  • 1
    Yes, that's it. You only know that the decrypted text will change when you change the ciphertext, but you don't know into what it changes.
    – fr00tyl00p
    Commented Oct 21, 2015 at 12:26
1

When creating an HMAC (Hashed Message Authentication Code), the message is only part of the hash. There needs to be a key as well. This key is known only to the server.

In python:

import hmac
from hashlib import sha256

msg = "The cow jumped over the moon."
key = "My key."

print hmac.HMAC(key, msg, sha256).hexdigest()

Without the key, anyone could modify the hash. So it is important to have a strong key. Once the key is leaked or guessed, the HMAC becomes useless.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .