# Tag Info

24

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

7

XTS is designed so that the plaintext and ciphertext sizes are the same. This is "needed" for disk encryption in order to preserve the sector size. However, when you are encrypting your disk at the file level, this is a completely irrelevant issue. Also, XTS is not "ideal" in the sense that it's not truly a wide block cipher (defined as a pseudorandom ...

7

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

7

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

6

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

6

Background. PBKDF2 has a stupid design where generating two blocks of output costs the legitimate user twice as much as generating one block of output, without necessarily putting additional cost on the adversary's task of confirming a password guess. This is because each block of PBKDF2 output is generated by iterating the PRF on distinct initial inputs, ...

6

Actually, you can't remove the $E_{k_2}$ as you did. You had: $$C_{j} = E_{K_2}(P_{j} \oplus (K^\prime \otimes \alpha^j)) \oplus (K^\prime \otimes \alpha^j)$$ Let me replace the term $(K^\prime \otimes \alpha^j)$ with $K^{\prime\prime}$ and eliminate the $j$ to makes things easier to read. The result is: C = E_{K_2}(P \oplus K^{\prime\prime}) \oplus K^{\...

5

A tweak collision seems to only disclose whether the same plaintext was encrypted with the same key and the same tweak Actually, XTS will disclose whether related plaintexts were encrypted with the same key/tweak. Specifically, if two plaintexts had the same value for block N, then after encryption (assuming the same key/tweak), the ciphertexts would also ...

5

No, this does not make a deterministic authenticated cipher, unless you're using a secret CRC as a MAC. How do you break it? First, find a pair of messages $m = m_1 \mathbin\| m_2$ and $m' = m'_1 \mathbin\| m'_2$ so that $m_i \ne m'_i$ and $\operatorname{CRC}(m) = \operatorname{CRC}(m')$. (Finding collisions in CRCs is not hard.) Then: Query the oracle ...

5

As Paŭlo Ebermann notes in a comment above, the time cost of a proper MAC calculation is almost certainly negligible compared to the cost of reading or writing the data on the disk. Applying a MAC to each encrypted sector (and the sector number used to derive the IV) will fully protect your data against most forms of tampering. The main drawback of this ...

5

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

4

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

4

Use XTS for whole-disk encryption. It is designed for that purpose. Definition of XTS mode in wiki is under the Disk Encryption Theory which says enough i think :) In GCM, for a fixed key each, IV value must be distinct. This makes it disadvantageous for encryption of large files. From an early GCM question: GCM is bounded to encrypting about 68 GB ...

4

From what I understood, data units are sectors, so a sector can have at most $2^{128}-2$ blocks but you can only encrypt $2^{20}$ blocks which cannot be correct (it seems too little compared to a disk's capacity). The data unit is the sector, yes, but both of those quotes only talk about the length of a single data unit. The larger number in the latter ...

4

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, so the ...

4

It depends. (Usual answer to this kind of questions. We would need more details about the data damage to answer) XTS encryption mode is short for XEX-based tweaked-codebook mode with ciphertext stealing, and XEX stands for Xor-encrypt-xor. Let's look how the XEX mode is defined: (image from wikipedia) XTS definition changes only how the last block is ...

4

However all typical disk sector sizes are divisible by AES block size (128bit). So does that mean that disk encryption uses XEX mode and not doing cipher-text stealing at all? Given that XTS is indistinguishable from XEX if the block size divides the sector size, yes disk encryption in practice nearly always uses XEX / XTS. While in theory you could now go ...

3

From Ptaeck's site (here) (You linked this) It’s complicated. It’s a wide-block tweakable mode built out of a narrow-block tweakable mode, it uses two keys unnecessarily, and it uses ciphertext stealing to handle variable-length inputs. Another way to say “complicated” is “hard to prove correct”. This essentially means that it's easy to implement ...

3

You then take $T$ and left shift it one bit. If the carry from that operation is a 1, then you XOR in 0x87 on the bottom byte. That becomes the pre- and post-crypto XOR material for the next block and so on. What's going on here is a finite field multiplication in the field $GF(2^{128})$, modulo the irreducible polynomial $x^{128} + x^7 + x^2 + x + 1$; if ...

3

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

3

You're trying to compare authenticated encryption with disk encryption. GCM is used to solve 2 security problems at once: encryption and authentication. GCM is designed such that only someone knowing the key can modify ciphertext without raising alarms. This requires additional data to use as an authentication tag. XTS, on the other hand, only partially hold ...

2

This appears to be a better question to offer this answer to, in addition to Seth's great answer to the question: "What is the advantage of XTS over CBC mode (with diffuser)?". Non-malleable file encryption using AES XTS 256? You'll want to add authentication to the encryption. See paragraphs 2 and 4 below. Links to an article and source code for ...

2

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

2

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

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

From §5.1 ‘Data units and tweaks’, p. 4: Each data unit is assigned a tweak value which is a non-negative integer. The tweak values are assigned consecutively, starting from an arbitrary non-negative integer. When encrypting tweak value using AES, the tweak is first converted into a little-endian byte array. For example, tweak value 123456789A16 ...

2

They don't issue cryptographer's licenses to pseudonymous carrion fowl, so I can't rightly claim to be a cryptographer, but I can confidently say that if there is any problem here it is far more likely to arise from unrelated mistakes in VeraCrypt's protocol or implementation than in cryptanalysis of AES-XTS. Any distinguisher on AES-XTS implies a nearly-as-...

1

I assume you mean "random access" by "decrypting arbitrary part of ciphertext, operate on it, and securely encrypting it again". The XTS mode is designed as a "Full-Disk Encryption" mode, which means it does not have the slightest concern with authentication. From practical perspective, I recommend having a keyed tuple or tree hashing mode for ...

1

Analyzing the risks and correctly setting the threat model is important when choosing the encryption schemes. If the attacker is a passive attacker, that he can only read the hard disk while transmitted, as it pointed out in the comparison of the XTS vs CTR question, there is no benefit against for passive attacker. When the attacker, however, is an active ...

1

XTS works by encrypting each plaintext block with XEX, and specifies which tweak to use. The benefit of applying the tweak to the blockcipher output is that it makes XEX secure against chosen-ciphertext attacks. If T is the tweak and E is the underlying blockcipher, we could consider a variant of XEX without the second application of the tweak: \$\mathsf{...

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