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?

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.

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.

  • 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 6 '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 6 '15 at 21:16
  • 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 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 from ElGamal encryption. – cpast Apr 6 '15 at 21:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.