Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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.

share|improve this question
2  
If your IV is out in the open, anyone can XOR its hash with the XORed Version number –  rath May 21 '13 at 8:07
    
If the receiver already knows version, then you can use version as the associated data in SIV mode. –  Ricky Demer May 21 '13 at 9:01
    
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)$? –  fgrieu May 21 '13 at 11:46
2  
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. –  Maeher May 21 '13 at 15:13
1  
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. –  Maeher May 21 '13 at 20:24
show 4 more comments

1 Answer

up vote 3 down vote accepted

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.

share|improve this answer
    
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. –  Luke May 22 '13 at 0:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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