# Reusing AES-CTR Keys and IVs for File Encryption

I’m implementing some file encryption module with random-access capability and AES-CTR seems the right way to go.

I understand that reusing Keys and IVs can expose the file to ‘Stream Cipher Attacks’ when portions of the file are being modified (assuming previous versions of the file are still available).

I want to avoid re-encrypting the entire content of the files when they are modified and so I thought to combine CTR with ECB. First encrypt the block with CTR and then re-encrypt the resultant cipher text with the same key again:

CTR-Cipher = Plain xor AES(IV + counter, Key)
Final-Cipher = AES(CTR-Cipher, Key)


Would that allow me to reuse the key and the IV? Or are there other secure alternatives to support random-access based encryption without a lot of re-encryption?

-

Yes, there are secure alternatives to support random-access based encryption.

I did not come up with a way to break the proposed combination. Still, instead of inventing a new mode, I would recommend to take consider existing modes for this kind of operation, such as XTS mode. The existing modes are more studied, and (in some ways) more efficient. XTS mode (as well as some other modes) only invokes cipher once per block of input. Rogaway has created a paper describing the most common modes of operation, which contains good study of XTS mode, including some critique.

# Alternative: IEEE P1619

IEEE P1619 has developed standards for disc encryption. These standards contain cryptographic mechanisms for keeping disc storage encrypted. As disc storage (often) requires frequent rewrites of disc sectors, these standards capability of rewriting sectors.

IEEE P1619 specifies both length expansionless encryption mechanisms and mechanisms with length extension (P1619.1). XTS mode is one of the most commonly used cipher modes of operation, if you want to avoid length extension. It likely proves the security features you expect from CTR with ECB combination, i.e. it works on narrow blocks (16 bytes) and allows you to pass in index of the sector. Some narrow block a problem. In that case, you mate take a look at wide block encryption such as EME2, XCB from P1619.2.

# Alternative: Per Block IV (Traditional)

Just for reference I also mention traditional (well studied way to do this). This approach may prove useful in case you lack cryptographic library or hardware with appropriate modes from P1619.

A well known way to do random-access based encryption is to consider data as blocks and generate random IV per each block each time a block is updated. This of course mess that the encrypted data will expand, but the percentage is not very large: consider e.g. one kilobyte blocks and 16 byte IVs: $\frac{16}{1024}\approx1.6\%$. This is only a small cost. Note: When expanding length, it is commonly good idea to add authentication tag as well.

-

Your combined mode of operation is not as easy to attack as a two-times-pad (i.e. stream-cipher with fixed IV used twice), but it still has some weaknesses.

For example, an attacker which did read your file before and after the change can easily find out which 128-bit-blocks of the file did change and which ones stayed the same. Depending on the file format this might or might not be a problem.

What often is done is to split the file (or disk volume or similar) into blocks (sectors) of larger size – about the size of what can be accessed (written/read) at once. (This depends a bit on your disk, but 4 KiB seems to be in the right order of size). Each sector gets its own random IV, which is stored at the beginning of the sector (this makes for a small size overhead). Reencrypt the whole sector when something changes.

Or use a mode of operation which is actually meant for disk encryption.

-