Assume the following structure:

version | iv | ciphertext | HMAC(version | iv | ciphertext | ..., key)

The version starts out to be a "random" 64-bit number. It identifies the key used to encrypt the ciphertext for the purpose of key rotation (version is not, nor does it contain any part of the key). For every message encrypted by the same key, version is the same. The rest of the text, starting with a random iv, is always different.

Is there any reason I need to protect version? If an attacker knows the version the most they can do is identify a group of ciphertext that was encrypted with the same key.

The ciphertext itself has validity period of it's own. The data should be updated around the same time as the key is rotated. The rational behind version is to allow the ciphertext to be updated gradually as-needed.

Would obscuring the version in some way add any benefit, even small? Something like this:

$Version_n \oplus Hash(iv)_n$

I know this adds no real security benefit. If version doesn't need to be protected, the most I'm going for is to make it appear random.

  • 2
    $\begingroup$ If your IV is out in the open, anyone can XOR its hash with the XORed Version number $\endgroup$
    – rath
    May 21, 2013 at 8:07
  • $\begingroup$ If the receiver already knows version, then you can use version as the associated data in SIV mode. $\endgroup$
    – user991
    May 21, 2013 at 9:01
  • $\begingroup$ The proposal $Version_n \oplus Hash(iv_n)$ (notice the fix) is security by obscurity: security lies in the method, not a key. Hiding the key version, as well as including it in the HMAC, looks pointless to me. If its desirable for some reason to hide the key version, what about replacing $Version_n$ by $Version_n \oplus HMAC(HMAC(version | iv | ciphertext | ..., key_{version_n}), longtermkey)$? $\endgroup$
    – fgrieu
    May 21, 2013 at 11:46
  • 2
    $\begingroup$ The question is: Does exposing said information cause any security-loss in your application? If no, then there is no reason to try hiding it. If yes, then security by obscurity is definitely not the solution. $\endgroup$
    – Maeher
    May 21, 2013 at 15:13
  • 1
    $\begingroup$ To answer that we would need to know what exactly your security goal is and what exactly the application is. For the confidentiality it shouldn't matter. But if your application needs some kind of unlinkability or something like that it could be a problem. We simply do not have enough information to judge the security of what you are trying to do. $\endgroup$
    – Maeher
    May 21, 2013 at 20:24

1 Answer 1


For most purposes, you probably don't need to provide confidentiality protection for the version field.

There may be some settings where the version field allow traffic analysis, and to analyze that, we'd need to know so much detailed information about your particular protocol that the question would probably become too localized to be a good fit for this site -- but for most circumstances, you don't need to worry about confidentiality protection.

I do recommend you do apply integrity protection (e.g., the MAC, as shown in your question). The word "protect", in cryptography, is ambiguous, and it's important to understand that confidentiality protection is not the same as integrity protection.

  • $\begingroup$ I would assume that, in most cases, you'd want to include every field in the MAC so nothing can be modified. Since a past version has a short life anyway, I agree with your assessment that version doesn't have to be confidential - which is what I was trying to determine. From other comments, it seems also pointless to mask the version as well. $\endgroup$
    – Luke
    May 22, 2013 at 0:28

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.