Integrity of messages is a problem that is as old as messengers. In the old days, people would seal a message, they knew they couldn’t prevent interception and tampering, but they could make it tamper evident. To an extent.

A good example is the telegraph problem. Back in the wild west, banks would telegraph each other to verify account balances before handing over money for withdrawals. This was vulnerable to man in the middle attacks – someone could snip the wire and pretend to be a bank and reply to the request. Well, the bank can use ‘session keys’ but the person in the middle can still modify the message and just pass the key along. What if the bank has a unique number that is calculated based on the message. This number is:

• Unique to the message, so if the message has been altered, the number will change
• One way so the attacker can’t reverse the secret number to work out the message
• Fixed size
• Not a secret.

Well the man in the middle can change the message, recalculate the number (since the method is not a secret) and send the message. How can we stop this? How can we do this in a digital sense? By adding a shared secret to the message before calculating the special identifying number. This shared secret is known as a Message Authentication Code (MAC) or a Keyed Hash. It looks something like this (note the ‘|’ means concatenate):

our magic integrity code: hash(message | MAC)

The attacker doesn’t know our MAC, so they can’t create a valid hash. When the receiver hashes the modified message with the MAC, it won’t match the hash the attacker provided and they know it has been tampered with

Reflection

Integrity is critical to ensure that messages are valid. We can try to prevent interception and tampering but we can’t guarantee it. We can however establish if a message has been tampered with by using a Message Authentication Code added to the message before doing our hashing – assuming the attacker doesn’t know our shared secret. Warning, fun times ahead.