I need to store a frequently-changing set of encrypted data in a database. This can be encrypted and decrypted with an internal key. The data is based upon other metrics within the system, mostly the number of times various things have happened.

Encryption in this case only provides security by obscurity, in that if a person figures out where this data is stored and has database access then they can simply 'roll back' this encrypted blob to an earlier version, thus reverting its contents to a past state.

An HMAC of the data wouldn't help, as an adversary could simply roll back the HMAC along with the message it represents.

Is there a way that I can, at least, detect cryptographically that this data has been rolled back?

My feeling is that I'll need to make some element of the stored data refer to the current state of the system, or make it time-based.

  • 1
    "if a person figures out where this data is stored and has database access" What's your threat model? Are you trying to implement some kind of DRM? Jan 15, 2020 at 22:48
  • What is the use of cryptographically detecting that the data has been rolled back or tampered with when the barrier to tampering it is so low, where the encryption is simply security by obscurity? Feb 15, 2020 at 1:42

2 Answers 2


The prevention of roll-back on Databases is not easy. Let's talk about rows.

  • Adding date and time will not help, you need to store the date of update locally and id of the data.
  • HMAC will not help, same as above
  • HMAC and date : will not help, same as above
  • Channing all rows will not help. The attacker can revert back to an old state in all of the states. You can store the last value of a chain, then you need to look for the validity of the chain.

Is there a solution?

Better use Merkle Tree, which is optimal and requires only log n data transfer. Keep the HMAC of all cells of a row in the last column of the row and use the Merkle tree on this column only. With this, you need only store one Hash value, locally.

If your application servers are also under threat, than you can uses either

  • a third party, or multiple of if so that in any conflict you can be sure about the change.
  • Another solution is using HSM in application servers to store the value.

There are some academic articles about the integrity and authenticity of the databases, most of them missing/hiding the rollback problem. The Merkle-Tree is the king.

  • This doesn't seem to address the problem at hand. What's stopping the attacker from rolling the Merkle tree back too exactly? Jan 15, 2020 at 22:45
  • @JosephSible-ReinstateMonica Storing the value on the application servers. If the database has been changed then it can be detected. If you are talking about the complex attack that the attackers attacked both the application servers and the database server than you may need a third party to store the value for you, too.
    – kelalaka
    Jan 15, 2020 at 22:48
  • If the application servers can store state more securely than the database, then why even have a database? And in that case, again, why do you need a Merkle tree? Jan 15, 2020 at 22:49
  • @JosephSible-ReinstateMonica do you ever know about the Merkle Tree? It only stores one value hash!
    – kelalaka
    Jan 15, 2020 at 22:49
  • But a Merkle root is the same size as the result of an HMAC. Jan 15, 2020 at 22:51

Not without making what you're building be fully online. Otherwise, imagine running your software in a VM without networking, letting it make some change, then rolling back the whole VM to the snapshot. There's clearly no way to detect this.

  • That is not true. You can store a Hash/ of the VM and check the hash of it before opening. This like what people do on ubuntu CD/DVD ISOs.
    – kelalaka
    Jan 15, 2020 at 23:06
  • You can't check the hash of a VM that you're stuck on the inside of, and even if you could, without being online, what will you check it against? Jan 15, 2020 at 23:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .