
Cryptographic File Systems Performance: What You Don't Know Can Hurt You (2003) - tomashton
https://www.filesystems.org/docs/nc-perf/index.html
======
hlieberman
This is pretty dated -- the document is 14 years old, at this point. While it
was an accurate study of its time, many of the technologies referenced have
been replaced --- and some were found to be defective.

~~~
lvh
Yep. There are other things that significantly affect perf in addition to
newer technology (like XTS): for most users, the block device is an SSD, and
for most users, your CPU knows how to do AES quickly. Both have significant
improvements to performance, up to the point where turning on FileVault 2 for
a Mac is a no-brainer now.

------
notacoward
Needs a [2003] tag. Great for its time, but everything from the systems they
evaluate to the benchmarks they use to the hardware they ran on makes this
almost inapplicable today. It would be fantastic to see an updated version.

------
os10000
Please read up on ZFS. Once your inner computer scientist has overcome the
"blatant layering violation", you will understand how they minimise the
encryption cpu effort with much caching, and how they leverage transaction
groups to reduce latency impact. The corruption issue is being addressed by
very large blocks each with their own checksum (outside the crypto container),
scheduled onto independent devices and a scrubber to regularly re-validate the
integrity. Yes, yes, this was published a bit after the linked article.

------
pmoriarty
I've long refrained from encrypting my file systems because of a worry that a
tiny bit of file system corruption (like during a power outage, or from stray
cosmic rays) could cause the entire file system to become un-decryptable and
thereby losing all my data. Is this a valid concern or can are encrypted file
systems as resilient as unencrypted file system to such limited, local
corruption?

~~~
lvh
Most modern disk encryption mechanisms have settled on XTS (with AES). That
includes dm-crypt, FileVault2, BitLocker... XTS is effectively a way to build
a really wide block cipher: typically 512 (== 1 classic sector) to 4096 bits
(== 1 modern sector) instead of the usual 128 bits (for AES). (Yes, yes.
Technically a tweakable block cipher, four points for Gryffindor &c.)

With these systems, file system corruption is not a significantly different
issue than it is with other systems. It is not the case that a filesystem is
much more likely to become entirely or largely inaccessible than it would be
if it had not been encrypted, unless if course if you lose the key!

I'd be in remiss if I didn't mention that while XTS is the standard, it fixes
a very specific kind of problem, and you probably still want something on top
with a more traditional form of encryption for specific sensitive files. To be
clear, the advise is not "don't use FileVault 2"! It's: "do not only use FV2".
My work machine, for example, is FV2, but all important credentials are GPG'd
using a smart card that's normally not attached to the machine.

~~~
gruez
>typically 512 (== 1 classic sector) to 4096 bits

it's bytes

~~~
lvh
Oops! You are of course correct :)

