[ynniv]

block crypto is typically not authenticated

Is this simple oversight?

you'd like your cryptosystem to have as much information to work with as possible, and one nice bit of information for it to have is where files begin and end.

Doesn't this leak information? An attacker knows very little about an opaque block, but may be able to use file length and modification order to some advantage.

[tptacek]

No, it's not simple oversight. Here's my best stab at an explanation:

http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

Regarding information leakage: both schemes leak some degree of information (for reasons I get into in that post, XTS is deterministic). But because encrypted filesystems don't have to respect strict block boundaries, they can do a variety of things to limit or eliminate leakage. It's much harder for block device crypto to solve this problem.

Naive encrypted filesystems don't, of course. Like I said, I'd have a hard time making a recommendation between Truecrypt and EcryptFS.

[ynniv]

Regarding authentication it only mentions performance and block failure. It seems that your company does use encrypted DMGs, so are these problem mitigated by having a larger encrypted unit size and reliable data storage?

[tptacek]

Think about it. How do you authenticate a block device?

Do you:

(a) Authenticate the ciphertext of the whole device as a unit? So, any time you update any block on the entire disk, you also need to update the MAC tag? What happens if you do that? Any block corruption occurring anywhere on the device breaks the MAC tag for the entire disk.

(b) Authenticate each individual sector? Where do you store the MAC tags? There's an awful lot of sectors on a disk. Also: what does it mean to have a single corrupted sector in a file consisting of many sectors?

(c) ???

Of course, the answer is that full-disk encryption tools (ie simulated encrypted disks, like Truecrypt) don't authenticate. There's no good place to store the tags and no good units of data to authenticate.

What does it mean that encrypted disk sectors aren't authenticated? Well, it means two things:

(i) Attackers can perform targeted rewrites of data on the disk, typically at a full-sector level; in practice, this means that they can randomize any sector of the disk, and the encryption software can't know that the now-random data isn't real data, nor can the operating system. By aiming these random blocks at trusted metadata or executable binary code, attackers can potentially turn this ability into a much more serious attack.

(ii) Because the encryption software must trust the outcome of decryption, even when attackers tamper with data to make its output random, attackers gain the ability to feed chosen ciphertext into the encryption software. This sounds like an academic concern, but it's the basis for many of cryptosystem attack classes we've learned about in the past decade, most notably the padding oracles.

[mhogomchungu]

>Authenticate each individual sector? Where do you store the MAC tags? There's an awful lot of sectors on a disk. Also: what does it mean to have a single corrupted sector in a file consisting of many sectors?

openbsd does this with their geli tool[1]. Look at the tool's documentation for the "-a" option.

The authentication stuff are stored on the sector itself. I remember looking at their implementation a while ago but cant seem to be able to dig up the documentation link at the moment.

[1] http://www.freebsd.org/cgi/man.cgi?query=geli&sektion=8&manp...