Cryptography for Mere Mortals #10
An occasional feature, Cryptography for Mere Mortals attempts to provide clear, accessible answers to questions about cryptography for those who are not cryptographers or mathematicians.
I promised that we were done with hashes, but there’s one more set of interesting and powerful uses for them that’s worth discussing: Message Digests (MDs), Message Authentication Codes (MACs*), and Hashed Message Authentication Codes (HMACs).
A Message Digest is just a hash of a message. MDs are useful to verify that the message was not accidentally damaged in transit. These were useful in the days of dialup and other technologies; with modern TCP/IP, not so much, although some websites will list an MD along with a download so that you can verify that you downloaded what you meant to get (the idea is that you’ll generate a hash after the download and manually verify it).
More interesting are MACs and HMACs. These are essentially the same thing in practice. A MAC takes a message plus a secret key (a password, if you will) and creates a token—a short piece of data, a “magic value”—from that. Since the two sides—the sender and receiver—are the only ones who know that key, a MAC provides both integrity (the message has not been altered since sending) and assurance (the sender is who we think it is).
A MAC need not use a hash function to generate the token (it could use an encryption algorithm, for example), but with the speed, ubiquity, and security of modern hash algorithms, typically hashes are the method of choice. And a MAC that uses a hash function is an HMAC.
So if you have a client that needs to send a transaction to a server, then instead of adding a login step with userid/password, you instead make it atomic, sending one request: the transaction plus an HMAC. That is, the contents of the transaction are hashed using the previously agreed-upon password as a salt, and sent along with the transaction as a kind of single-use password.
Since the server knows the password, it can take the contents of the transaction, hash them (again using that password as a salt), and thus authenticate the request.
Even if an attacker is somehow able to intercept the request, the request itself cannot be changed, nor can bogus requests be made: without the secret key, the attacker cannot create a new HMAC that the server will accept.