I am trying to secure user's profile in database (data at rest). This user's profile is downloaded only after successful authentication at server (based on user's entered password and user name).

The user's profile is encrypted using AES-GCM

  1. PBKDF2 derived symmetric key (derived from entered password)
  2. A random salt
  3. The nonce

The operation returns me the encrypted data and a MAC (Message authentication code)

I need to decrypt the data without authenticating from server using the same entered password

  1. New PBKDF2 derived symmetric key
  2. Same salt as used for encryption
  3. Same nonce as used for encryption
  4. Same MAC as generated from encryption

My question is where (along with encrypted data? somewhere else?) and how (encrypted? hashed?) should I store the MAC in database?

  • 1
    $\begingroup$ Note that AES-CMAC is a MAC and not an authenticated encryption mode. The corresponding encryption algorithm would be AES-CCM. And post-processing the MAC-tag is not neccessary. $\endgroup$
    – SEJPM
    Commented Feb 10, 2017 at 19:46
  • $\begingroup$ I am using AES-GCM to encrypt and decrypt/authenticate. My mistake. Are you saying I shouldn't have to save the authentication tag or MAC to decrypt the data back? $\endgroup$ Commented Feb 10, 2017 at 20:02

1 Answer 1


My question is where (along with encrypted data? somewhere else?) [...] should I store the MAC in database?

In theory you can store the MAC wherever you want, as long as you store it and get the association right between MAC and ciphertext.
Practically however it's smartest to append the tag to the cipher text. This minimizes the chances that you screw up the association somewhere and it will make your implementation compatible with most libraries, which more often than not just append the tag and don't provide you explicitely with it.

[H]ow (encrypted? hashed?) should I store the MAC in database?

Usually the MAC is stored in plain and this is actually covered by the usual security games and reductions. So an attacker can't even break the security of the scheme (ie decrypt messages in any attack model or forge a message) if the MAC-tag is available in plain. Thus there's no need for further encryption or hashing.


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.