1

I understand what a hash is, basically we calculate a hash and append it to the message and send it to the receiver. If someone alters the message, the receiver will know because there would be a different hash value.

Since hash algorithms are well-known such as MD5, SHA1, if there is a man in the middle attack, can he then alter the message and regenerate the hash based on the altered message and send it to the receiver? The receiver will not know it is an altered message by calculating the hash, correct?

William
  • 105
  • 5
xvi_16
  • 27
  • 1
  • 1
  • 2
  • This is already covered by several other questions on this site: [Why we use GPG signatures for file verification instead of hash values?](http://security.stackexchange.com/q/31836/971), [Does hashing a file from an unsigned website give a false sense of security?](http://security.stackexchange.com/q/1687/971), [when people say a file has a checked md5 hash, what exactly does that mean?](http://security.stackexchange.com/q/5161/971), and [How can I check the integrity of the downloaded files?](http://security.stackexchange.com/q/43332/971). (cont.) – D.W. Apr 06 '15 at 19:06
  • 1
    I found all of these in just a few minutes using search and by perusing the [tag:hash] tag. In the future, please do more research before asking -- we expect you to do a significant amount of research before asking, including searching on this site for similar questions. – D.W. Apr 06 '15 at 19:07

2 Answers2

4

Yes, that's correct. That's why if you're using a hash for data integrity then you must deliver the hash by separate means (eg. posting the hash with your twitter account). To get around this problem in emails, rather than using a hash you can use public key cryptography that allows the receiver (and anyone else) to verify the signature using your public key, but the signature cannot be created without your private key. This is what PGP uses.

Aron Foster
  • 1,204
  • 2
  • 11
  • 19
1

To expand on @aron-foster's answer, the way that this is done in public key cryptography is to first hash the message and then encrypt the hash using the sender's private key.

In public key cryptography, as you likely know, data encrypted with one of the keys can only be decrypted with the corresponding key. This means that when the hash is encrypted with the private key, the sender's public key can then be used to decrypt it, thus verifying the key.

However, even with well known hashes (let's say, a 'known good' hash set used for file integrity), the issue that you raise is a potential problem. What if an attacker not only modifies the file but discovers a hash collision that allows him to manipulate the protected data while retaining the same hash?

This is the reason that file integrity tools (rather than installation validation tools like RPM and APT) will track multiple hashes for the tracked objects. In this way, even if one hash collision is found, it is beyond belief (today) that you could modify a file and maintain more than one hash unchanged.

David Hoelzer
  • 615
  • 4
  • 9
  • 3
    No, that's *roughly* how signatures work *in RSA.* Even there it's not quite correct (you use different padding schemes and different key management strategies; the encryption keypair is separate from the signing keypair), while in other signature schemes it's totally wrong (there is no similarity between signing and encryption). – cpast Apr 06 '15 at 17:38
  • @cpast would you mind providing a reference or two for the claim that there is no similarity between signing and encryption? – David Hoelzer Apr 06 '15 at 21:16
  • http://crypto.stackexchange.com/a/838/18113 for one. Look up DSA (and by extension ECDSA). It does not even slightly resemble encryption, and you cannot retrieve the hash from a DSA signature alone. In RSA there is similarity, but [the actual algorithms are different](http://crypto.stackexchange.com/a/15998/18113) because they have different padding mechanisms (without padding, RSA is extremely insecure, so the padding is a necessary part). ElGamal signing is likewise [completely different](http://crypto.stackexchange.com/a/13179/18113) from ElGamal encryption. – cpast Apr 06 '15 at 21:33