TL;DR

Sometimes digests are useful for validating data against malicious changes.

We already saw in Digest and identifiers that calculating a message digest can be useful for generating hopefully unique data.

The same technique, extended, can also be used to apply a seal to a piece of data. This is what HMAC is for:

In cryptography, an HMAC (sometimes expanded as either keyed-hash message authentication code or hash-based message authentication code) is a specific type of message authentication code (MAC) involving a cryptographic hash function and a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and the authenticity of a message.

In shorts, using a simple digest function to generate this seal isn’t very robust. As an example, if you transmit this:

<message> digest(<message>)

then you can be reasonably sure that this will help you against transmission errors, but if your stuff is taken by a malicious attacker… they could change the message and the digest and make it appear like everything was fine:

<message'> digest(<message'>)

So… something better is needed. This is why, in HMAC, there is also a secret cryptographic key: it’s a shared key between the two endpoints, which is used to generate the digest and also to make sure that nobody without the key will be able to generate it.

How the key is used is dependent on the algorithm; just as an example, let’s assume that the digest is calculated as follows:

<message> digest(<key><message><key>)

If you want to change the message, you have to know the key to regenerate the digest.

As I said, this is not necessarily the most robust way to use the key, so stick to the expert’s advices and use peer-reviewed algorithms and implementations!