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


16

Authentication and probabilistic encryption are two desirable features which each take up a small amount of extra space. And you are absolutely right that the percentage of space consumed is of no concern in most scenarios. But as the other answers also point out that means you can no longer fit a logical sector inside a physical sector of the same size. ...


14

So, are there reasons for not using authentication that I'm missing? I believe that the real reason is not actually space, but time. As you said, storing the tags would not require that much space. However, the tags need to be stored somewhere, and whenever you read the sector, you also need to read the sector containing the tags as well. So, unless you ...


12

With 4096-byte sectors, space is a complete non-issue, less than 1 % Problem 1: 10GB per TB is not a "complete non-issue" for many people. Problem 2: If the checksums are inside of their data blocks, there is a huge compatibility problem. The data per block is less than 512/4096, but many (really many) programs and kernel parts of pretty much all ...


12

The key is not stored with the encrypted data, the encrypted key is. This is part of the header. In short, when the volume is created a random key (the master key) is generated and this random key is encrypted using a key derived from the passphrase, and spread out (using an algorithm called 'afsplit'). This key derivation is designed to take a relatively ...


11

AES has fewer rounds than Serpent so AES should be faster. The number of rounds by itself is meaningless. Some ciphers have a few complex rounds and others have many simple rounds. See my answer to Why does SHA-1 have 80 rounds? for a related explanation. There is no speed decrease with bigger key size in Serpent while there is in AES. The performance ...


9

Roughly your password is used to encrypt a MasterSecretKey. Then you use this MasterSecretKey with a symmetric algorithm to encrypt or decrypt your data (the disk sectors). They eight key slots in LUKS are eight different encryptions of the same MasterSecretKey under eight different passwords. See also this image: (original web page: http://auto0.info/...


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

The threat it protects against is uncommon Encryption protects against an attacker who gains hold of the data. The typical threat is the theft of a laptop or a backup tape, the compromise of a remote backup server, etc. Who cares whether the attacker can modify the data? You aren't going to use that copy of it anyway. Once the attacker has gained access to ...


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


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


5

The problem is not to store an IV but to store an authentication tag. I don't know about any other products that solve this problem in a way similar to BitLocker. LUKS uses XTS by default, and TrueCrypt supported LRW and XTS, among other modes. Neither of these two modes provide any diffusion. Information about various modes for disk encryption is available ...


5

The standard for full-disk encryption (FDE) is XTS mode or ESSIV-AES-CBC. XTS tweaks each block within each sector differently (and hence avoids ECB's problems) and is considered the best choice available at the moment. ESSIV-AES-CBC works by using AES-CBC with the IV being the hash of the sector index. The problem with this mode is that you can flip bits ...


5

I think the thing you are looking for is "escrow" as in http://en.wikipedia.org/wiki/Key_escrow. Be aware though that the security of your system is reduced to the hardness for an attacker to find the master password which might be much easier than breaking the disk encryption scheme


5

Yes, EME is a wideblock cipher. Theorem 1 (in Section 4, top of page 5) states that EME is secure as a wideblock (tweakable) cipher under the assumption that AES (or whatever blockcipher you use) is secure. Specifically, to someone who doesn't know the key, EME will look like a set of random, independent permutations (one for each tweak). This is true even ...


5

The answer is in what Apple means by "ephemeral session key". See the BlackHat session starting around 12:00 in. The raw file encryption keys are wrapped with a ephemeral key when outside the SEP (Secure Enclave Processor), the actual key is never exposed to the normal application processor. The ephemeral keys are bound to the boot session of the phone.


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

You can use the ecryptfs-add-passphrase command to add a passphrase to your kernel keyring, which will also print the signatures (hashes) to standard out. Once you've added a passphrase to the keyring, you might want to clear it, using the keyctl command. eCryptfs uses a PBKDF2-like, key strengthening algorithm of 65536 rounds of SHA512. (Disclosure: I am ...


4

I think it is often considered a principle in evaluating the quality of a cryptographic setup to start with the assumption that the opponent is aware of the algorithm and the only variable unknown is the key. Given this, there are not many cryptographically motivated security benefits/differences, given you use the same cipher (+ block chaining mode of ...


4

$GF(2^{128})$ is a finite field with $2^n$ elements. There are a number of ways to represent this field. For example, a binary vector of length 128, or polynomials of degree 127 where the coefficients are 0 or 1. You could even choose to represent them as integers between $0$ and $2^{128}-1$. These are the elements of the finite field. In addition to the ...


4

The problem with full-disk encryption is that you don't want to "waste" space on authentication tags (because it would result in odd sector sizes or in a large latency / overhead on-disk). So we can't have tags, but also don't want to completely give up on the nice features authentication offers, especially the fact that you can detect manipulation. With ...


4

Why isn't this construction used instead of XEX? Because XEX takes a block cipher and constructs a tweakable block cipher out of it, whereas this construction, usually called Even-Mansour, takes a permutation and constructs a block cipher out of it. Surely unkeyed permutations should be faster than keyed ones since they do not have a key schedule, is ...


4

Block cipher encryption $$\operatorname{Enc}(K,P): \{0,1\}^k \times \{0,1\}^n \rightarrow \{0,1\}^n$$ is a permutation where a $K \in \mathcal{K}$ select a permutation from all possible permutations of $\{0,1\}^n$. Using $$\text{IV} = \operatorname{Enc}(\operatorname{Hash}(K) , S)$$ will guarantee that the output is unique, not repeating, since the $\...


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

If I had chosen a 25-character key would this process be faster? That would depend entirely on how Diskcryptor was designed; but it appears it would not. According to the Diskcryptor homepage, Diskcryptor selects a random symmetric (AES, Twofish or Serpent) key, and uses that to encrypt the disk; it uses the passphrase (what you call the strong encryption ...


3

The iPhone is built with encryption inserted automatically when writing to flash memory and decryption inserted automatically when reading from it. This happens with all files, all the time. There is no concept of "decrypting a file and then opening the decrypted file", as there would be on a PC. No file can be decrypted without the proper key. Some files (...


3

As you know, it makes reading and writing the disk very slow if all the data in the drive is chained together. If so, writing to a drive of size $n$ at position $p$ will require $\Theta (n-p)$ time. One solution is the drive being divided into sectors, and each sector being chained. The IV of each sector can be attained using ESSIV. it generates IVs from a ...


2

In order to create anything but garbage sectors in an encrypted file system, you need to have the secret key anyway, so there is only little gain. The only use case would be when you want to give data to others who should be able to read, but not modify it. That's only useful if you have run out of storage media so you cannot make more copies, want to ...


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