# Block Cipher Mode Amicable to Fast Key Change/Rotation Like XOR?

I'm working with documents encrypted in long term storage. When a client requests the document, the document should be delivered encrypted under a distinct key (distinct from the long term storage key).

For efficiency, I want to avoid decrypting the document under its long term key and then re-encrypting under a client delivery key.

Are there any FIPS 140-2 block cipher modes of operation that are amicable to a simple XOR for the transformation? That is:

• Client Key = Long Term Key ⊕ Random Key
• Client Encrypted Document = Long Term Encrypted Document ⊕ Keystream based on Random Key

When the client receives the document, he/she would:

• Decrypted Document = Decrypt (Client Key, Client Encrypted Document)

I think a mode like CTR is close to what I want since it Encrypts the Counter and then XORs it with the plain text, but I would like to avoid the "Encrypts New Counter" if possible.

The block cipher and approved modes are important because I'm constrained by FIPS 140-2.

Any insight or help would be greatly appreciated.

-

A better way to solve your problem is: on the server, encrypt the document under a document encryption key (a unique key that's specific to that document). The document remains encrypted in storage encrypted under this document key. When a client requests the document, send the client a copy of the encrypted document, as well as an encryption of the document key encrypted with the client's key. Now the client can recover the document key and then decrypt the document.

This will be very efficient and will meet all of your requirements. And, it is implementable using only standard cryptographic primitives approved in FIPS 140-2.

If you ever need to change the document, you should change its document encryption key to a new, unique key chosen independently of the previous version. Re-encrypt the new version with its new unique key. This way, users who have previously downloaded the old version of the document don't automatically get access to the new version (unless you decide they should be allowed to). This lets you implement revocation to the extent that revocation is possible in this setting. Thanks to DrLecter for this suggestion.

-
Maybe I've misunderstood the point, but I was assuming the transfer key was generated by a CSPRNG server side as in any hybrid encryption scheme? As such, I don't see how this opens you up to related-keys any more than other hybrid schemes. –  figlesquidge Dec 11 '13 at 10:21
Thanks D.W. The thing that worries me about the scheme is everyone shares the document's key. I think it suffers the same key management drawbacks as "everyone shares the wireless gateway password". Its nearly impossible to manage correctly over time with multiple users. If an employee leaves, then he/she will still has a valid key. The alternative is to log every document access and then rekey accessed documents when an employee exits. Or forgo logging and rekey every document when an employee exits. Or decrypt the document and then re-encrypt the document under a fresh key before delivery. –  noloader Dec 11 '13 at 11:17
@noloader, It's not a problem. Think about it this way: What does knowledge of the document key for document $D$ let you do? It lets you decrypt document $D$. But if you give that key to everyone who should be able to read $D$, then you're not allowing them to do anything they shouldn't be able to do. It's not the same "everyone shares the wireless gateway password" because my answer shows how to communicate the document key to a person. There is no revocation: once you've allowed someone to download document $D$, you're done, there's no going back: they've got a copy of $D$, period. –  D.W. Dec 11 '13 at 20:02
@noloader for revoking access a nice strategy is lazy revocation, i.e., revoking read rights does not bother you unless a document changes. As D.W. says, the users have already a copy of the file. However, if the document changes you re-encrypt to a fresh key. –  DrLecter Dec 11 '13 at 20:17
@DrLecter, thanks for the elaboration -- good point. If the document changes, you can consider the new version a new document (with its own key). I've edited my answer correspondingly. Thank you! –  D.W. Dec 11 '13 at 20:18