According to some government standards I need to be able to ensure some data in a database has not been tampered with.

My current idea is to store a MAC (HMAC-SHA256) next to each instance of the serialized data. The key will be stored in a separate location but the same key will be used for every MAC.

To detect tampering, I will read the data, compute the MAC again with the same key, and compare the computed MAC with the one stored in the DB. If they are equal, the data has not been tampered with, if they are different, than the data has been tampered with.

A weakness I am aware of is that if the key were to be compromised, we no longer can trust the MACs or the data. It would be possible to recompute the MACs, but they would only be valid for the data in the DB which we can no longer trust.

A few questions:

  • Is this a valid use case for a MAC?
  • Are there any major or minor flaws with this technique?
  • Is it OK to reuse the same HMAC key forever?
  • Would an asymmetric or AEAD solution be preferable?
  • 4
    $\begingroup$ What happens if someone rolls back the database to an old version? For asymmetric: is it OK if the verifier has the power to forge too? If so, don't bother with anything asymmetric. If you have a neatly packaged AEAD, it may be safer to use that than to cook up your own scheme—but beware that the contract for most AEAD is that you also supply a nonce that has never before been used, nor ever will be used again, with the same key. $\endgroup$ Aug 11, 2017 at 16:00
  • 1
    $\begingroup$ I am not sure what definition you use, but typically it only allows to detect tampering, it won't resist it. $\endgroup$
    – eckes
    Aug 12, 2017 at 18:46
  • 1
    $\begingroup$ @eckes: if someone can write into the database, there's nothing to prevent him from writing gibberish everywhere (or in selected fields). The only thing we can do from a cryptographical perspective is to detect it when he does it. $\endgroup$
    – poncho
    Aug 14, 2017 at 13:24
  • 1
    $\begingroup$ @poncho exactly, that's why tamper detection is the right word, tamper resistance typically only applies to hardware. $\endgroup$
    – eckes
    Aug 14, 2017 at 13:25
  • $\begingroup$ I incorrectly used the term "tamper-resistant" in the post title, what I mean is tamper detection. All I care about is knowing if the data has been tampered with, not preventing it. Sorry if there was any confusion. $\endgroup$
    – Isaac Zais
    Aug 14, 2017 at 13:31

2 Answers 2


First, you have to check if the HMAC integrity check complies to the governmental standard. In the USA, for instance, you have to check the FIPS specifications.
If that has been clarified then here are my answers:

is this a valid use case for a MAC?


Are there any major or minor flaws with this technique?

The one you already stated.

Is it OK to reuse the same HMAC key forever?

That is seldom a good idea, due to the "break once run everywhere" scenario. I would instead use a Key derived from a Masterkey. The Key is on the database and the Masterkey on an seperate isolated device. From time to time you should change the Key by a new derivation form the Masterkey and some well known data.

Would an asymmetric or AEAD solution be preferable?

An asymmetric solution makes less sense here, because you have to store the private key on your database system anyhow.


An additional problem depending on your exact setup:

Messages that are protected by the same MAC key can be exchanged. So you have to make sure that entire records are MAC protected as a unit.

  • $\begingroup$ Ah, I didn't consider this. Doesn't really affect my situation, but it's still good to know for future scenarios. $\endgroup$
    – Isaac Zais
    Aug 14, 2017 at 12:56
  • 3
    $\begingroup$ More generally: If the access path figures into your decision of what to do with the content of a record, you need to authenticate the access path too! $\endgroup$ Aug 14, 2017 at 13:25
  • $\begingroup$ One of those cases where the general statement can only be understood when you heard an example but still, a nice generalization. ;) $\endgroup$
    – Elias
    Aug 14, 2017 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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