# Integrity for mixture of encrypted/unencrypted database fields

I have multiple blobs each (symmetrically) encrypted with its own randomly generated key.

Now I want to encrypt these blob keys with user keys and store them in a database.

A table could have the following columns:

• blob_id
• user_id (unencrypted)
• blob_key (encrypted with user key)
• expiry (unencrypted)

Now I would like to ensure integrity and authenthicity of the unencrypted fields (for encrypted fields this is ensured using HMAC). Unencrypted data is quite short (in this case a key id and a date).

The use case is a large-scale E2EE encrypted cloud storage. So it should be massively scalable!

What is the best way to achieve this? Is it a good idea to use the same user key used for encryption also for signing the unencrypted fields? Which algorithm would you suggest for this type of data?

• This is a complex question. You should mention the possible scenarios. Do you consider the row deletion/insertion attacks? Dou you consider the roll-back attack? May 27 '20 at 20:55
• Each row is used to grant access to a block to a single user. So making sure a single unencrypted field is not changed is the point of this question. Inserting full entries doesn't matter since (blob_id,user_id) should be unique and blob_key is protected already. Deleting a row basically removes access to this blob for a single user, but I can't imagine a way to protect for this (except for redundancy) in case someone gains access to the database. May 27 '20 at 21:14
• Roll-back attacks for expiry shouldn't matter too much either, since one can't travel into the past in order to restore an expired entry. Roll-back attacks for user_id basically restore removed access for a user. So this should be avoided if possible although the user could still have stored the decrypted blob_key on his computer while he still had access. Is there a good way to protect against this without re-encypting the blob with a new key? May 27 '20 at 21:14
• Well, each of the attacks can have a solution up to some degree. One can protect the row just by the integrity since one has already encrypted data there. I don't see a need for the HMAC there. The Insertion can be prohibited by chain Hash/HMAC and keeping the last chain in the application server. This can also be used to detect deletion. For the freshness, Merle tree is the beast, however, the last chain can be also a solution if the application server data is correct. May 27 '20 at 21:19
• A row-based solution will be enough then. Add another column that stores the HMAC of the other rows. May 27 '20 at 21:45