Ask HN: How secure is the encryption offered by OS X's Disk Utility? - whitepoplar
======
jackjeff
It's state of the art block level encryption, however file system level
encryption such as what will be offered by the upcoming APFS is fundamentally
better.

In a block level encryption each sector is encrypted below the file system.
Doing the naïve thing of encrypting each sector with the encryption key is
fundamentally insecure. This is called the EBC mode of operation. There's a
nice picture of a penguin on wikipedia encrypted with ECB which demonstrates
this:

[https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation...](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_Codebook_.28ECB.29)

Secure mode of operations generally try to propagate the result of previously
encrypted blocks to the next ones. But this approach is not really suitable
for mass storage devices. You cannot re-encrypt all the sectors behind the one
you just changed. That's just impractical, since writing to sector #0 amounts
to rewrite the entire disk.

So in practice schemes like AES-XTS are used. They work by having some kind of
way of "tweaking" the encryption, so that it is different for each block
(avoiding the pitfalls of ECB), but in a way which allows random access to
sectors (i.e. in a way that is predictable). AES-XTS is a tradeoff for this
special use case but it is not as robust as more classical modes of operations
which would typically be used in an encrypted filesystem.

Details about AES-XTS issues: [https://sockpuppet.org/blog/2014/04/30/you-
dont-want-xts/](https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/)

~~~
0x0
If encryption is moved from the block layer to the file layer (on a per-file
basis), isn't there a risk of exposing unencrypted metadata such as filenames,
file sizes, file modification times etc? Or applications accidentally making
temporary (unencrypted) copies of files (perhaps in /tmp)? Or just by
accidentally cat > 'ing a sensitive file into the wrong directory, thus
accidentally leaving a plaintext copy around on the disk sectors? Am I wrong
in thinking block level encryption is a comfortable safety net for preventing
infoleaks for lost/stolen devices, since cleartext never hits the disk?

~~~
jackjeff
It really depends on the details of what the file system does. It is true that
older file systems did not encrypt metadata but that's not the case for newer
ones like ZFS or APFS.

The way I understand the scarce documentation about APFS is that all the
metadata is encrypted with a disk key. But on top of that the file system
encrypts user's files with a separate key.

So just like block level encryption plaintext never hits the disk.

~~~
0x0
That sounds great! Best of both worlds. Looking forward to see more details as
the betas progress.

------
purple-dragon
It's as secure/strong as the standards' based cryptographic method used, i.e.,
AES-128 or AES-256. If you're curious about the strength of FileVault, some
academics published a paper detailing their analysis (spoiler: they thought it
was pretty good):
[http://eprint.iacr.org/2012/374.pdf](http://eprint.iacr.org/2012/374.pdf)

~~~
iDemonix
As above, it uses known standards.

The weakest link is your password, relevant XKCD:
[https://xkcd.com/538/](https://xkcd.com/538/)

~~~
dogma1138
If your adversaries are not shy on using rubber hose cryptanalysis you are
screwed to begin with.

~~~
yborg
If your adversary finds the password on the post-it on your display, you are
also screwed, none of this has any bearing on the OP's question.

------
mherrmann
I never cared about encrypting local disks until my MacBook was stolen three
days ago. I have backups but the thought of someone having all my data is very
scary.

~~~
gaving
Nothing to hide; nothing to fear, right?

~~~
glumpyfish
Identity theft would be my biggest concern.

------
netheril96
If you are using disk utility to create an encrypted container file (as
opposed to an on-disk encrypted volume), you may want to check my open source
project
[https://github.com/netheril96/securefs](https://github.com/netheril96/securefs).
It encrypts at file level with AES-GCM, rather than AES-XTS at block level,
and the size is not fixed at creation.

~~~
wakkaflokka
How does this compare to something like VeraCrypt?

~~~
netheril96
VeraCrypt is similar to the disk utility created volume. It uses AES-XTS at
block level and the size of a container is fixed at creation time.

------
Heliosmaster
Another (related) question: how much slower is MacOS with FDE enabled?

~~~
karlshea
I'm sure there's some penalty you would see using a benchmark, but I enabled
FileVault on a 2011 MacBook Pro with an SSD in it a couple of years ago and I
didn't notice any difference at all with day-to-day usage.

I also have it enabled on a 2016 MBP, but I turned it on right when I got it
so I don't have a comparison.

From what I understand it's hardware-accelerated, but I don't know the
specifics.

------
coolio2657
It is standard security, nothing out of the blue for a default functionality
included in an OS, meaning it is of solid average quality, which, however,
unfortunately in the world of security means it is probably not up to par and
worth using.

The encryption standards it uses are pretty good, but that is not where
blanket whole-disk encryption (which I assume you're talking about) fail. For
example, hackers could analyze the preboot environment of an encrypted mac and
sniff out the password using a variety of methods. Simply put, whole-disk
encryption is too complicated and bug-prone process to really trust to closed-
source software.

As for single-file encryption, which is relatively neat and simple, Disk
Utility would probably do a pretty good job.

~~~
jackjeff
Full disk encryption only really offers security for the following 2
scenarios:

\- My computer/phone was lost and it was powered off. If my password is good
and secure, then I can be assured the data contained on the disk will not fall
into the wrong hands.

\- I need to securely wipe data off the disk, because I'm selling the computer
or something. Just deleting the master encryption key contained on the disk is
probably enough to render the whole thing unreadable. I don't need to spend
days using special software to overwrite all sectors multiple times.

Once the system is booted, the decryption key for the disk will be made
available to the OS, and all files will be made available to root processes.
At this stage, having a encrypted disk offers no more protection than having a
non-encrypted one.

~~~
yoz-y
> I need to securely wipe data off the disk, because I'm selling the computer
> or something. Just deleting the master encryption key contained on the disk
> is probably enough to render the whole thing unreadable. I don't need to
> spend days using special software to overwrite all sectors multiple times.

From what I have read, on any reasonably recent drive (made in last two
decades or so) a one time random pass is plenty fine.

~~~
Terribledactyl
That might be, but the main point here was that it's way faster. Do you want
to destroy a few MBs per drive or a few TBs?

