# Tag Info

15

Suppose you use the sector number times the number of AES blocks per sector as the initial value for CTR. If you successively store the content $M$ then $M'$ in the same sector $n$ then $E^{CTR}_n(M) \oplus E^{CTR}_n(M') = M \oplus M'$ (where $E^{CTR}_{n}$ is the encryption function with CTR mode and IV started for sector number $n$). CTR mode fails ...

14

XTS vs. Undiffused CBC. The issue here is malleability. Both XTS and CBC prevent an attacker from learning information about encrypted data. However, neither one completely succeeds in preventing an attacker from tampering with encrypted data. However, it's arguably easier to tamper with an (undiffused) CBC ciphertext than it is to tamper with an XTS ...

5

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 ...

3

If you don't mind that the ciphertext is longer than the plaintext, GCM is perfectly fine for storage encryption. Every time you write a block to disk, choose a fresh nonce and write the resulting ciphertext to disk. (You can ask for even stronger security properties, but then everything gets more expensive. Basically, build a tree structure for tags. Reads ...

3

From a draft of the IEEE spec, "An XTS-AES key shall not be associated with more than one key scope. The reason is that encrypting more than one block with the same key and the same index introduces security vulnerabilities that might potentially be used in an attack on the system. In particular, key reuse enables trivial cut-and-paste attacks." ...

2

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 ...

2

So is there any way to break XTS or a double application thereof in less time and/or space than expected? The expected time for standard XTS is time $2^{512}$ for 256-bit AES and $2^{513}$ time and $2^{512}$ space for double encryption. Yes, there are better attacks than that. With XTS a single sector is encrypted with a single $E_{K_2}(n)$ value, ...

2

XTS has been designed for disk encryption, where an attacker typically has access to the disk only a single time (when they steal/confiscate the device). When an attacker sees several ciphertexts encrypted using the same key, they can tell which blocks differ between the versions, but not the content of the blocks. Compare this with CTR mode, which leaks ...

2

The ZFS file system uses AES in CCM or GCM modes. This works because in ZFS the data and file system metadata is encrypted but the block pointers are in the clear, the AuthTag (MAC) is stored in the block pointer. ZFS also has a SHA256 based merkle tree based on the block pointers that is used for data integrity for resilvering and navigation purposes. ...

1

With OpenSSL the forward cipher for EVP_aes_265_xts is AES 256. The key being 512 bits, internally split into two 256 bit keys for each of the AES 256 ciphers used within the XTS mode of operation.

1

No, using XEX mode with $j = 0$ is not entirely safe. As noted in section 6 of the Rogaway (2004) paper (emphasis mine): "Some added care is needed to address the security of XEX. Suppose, to be concrete, that we are looking at $\mathsf{XEX}[E,2^{\mathbf I}]$ and $\mathbf I=[0\mathop{..}2^{n-2}]$. Let the adversary ask a deciphering query with ...

1

One answer would be nonce space: adding a tweak significantly increases the number of different nonce-tweak options you're allowed, thus increasing the maximum data that can be safely encrypted with a single key. Update: In his modes paper, Rogaway quotes an earlier source the CTR was dismissed due to trivial malleability. This makes a lot of sense, since ...

1

I don't see any reason to expect this to provide integrity (INT-PTXT or INT-CTXT). In fact, if $R1,R2$ were known to the attacker, I can show that in general it does not provide integrity: there exist some encryption algorithms that are IND-CPA secure but where your scheme does not provide integrity. (e.g., any stream cipher.) This sounds like a ...

1

Because XTS already solves the problem ESSIV is designed to solve. Disk encryption modes are meant for retaining some security despite the lack of space for a unique IV. They do this by making use of the sector number so that at least multiple copies of the same data stored in different places end up looking different. That is not sufficient for good ...

Only top voted, non community-wiki answers of a minimum length are eligible