[dm-crypt] [RFC PATCH 0/4] Allow file systems to selectively bypass dm-crypt
michael at kjorling.se
Fri Jun 16 16:47:15 CEST 2017
On 16 Jun 2017 16:31 +0200, from arno at wagner.name (Arno Wagner):
>> That implies that at the very least _anything_
>> that runs as root can now plant _plain text_ on storage media which is
>> intended to be fully encrypted.
> On the surfacte, root can do that anyways.
True enough. However, _when read back_ by normal means, unless _very_
deliberately and carefully crafted, that data will at least appear as
garbage, because the decryption of meaningful data with a random key
will most likely yield gibberish. This has two advantages:
(1) It is more difficult for an adversary to plant data that has some
particular effect when read _normally_ (through the container). To do
this, they basically would need to design a ciphertext that looks like
plaintext, yet when treated as ciphertext and decrypted with the
(presumably unknown) key becomes data with specific properties. Much
easier then to just write to the mapped device, which of course makes
the data written to disk be that which looks like gibberish instead.
(2) It can be plausibly argued that the data is not yours, especially
if it is a small chunk of plaintext-looking data in the middle of a
large volume of ciphertext. It could be remnants from before you
started using full-disk encryption, or it could in principle be any
other form of garbage. For certain threat models, this can be a _very_
And of course, for those who use FDE to facilitate storage device
decommissioning (just throw away the key and the data is effectively
unreadable), the _knowledge_ that _all_ data that touches the storage
device is encrypted before it does might even be the whole _point_ of
But I'm preaching to the choir, here. Or at least I hope I am.
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“People who think they know everything really annoy
those of us who know we don’t.” (Bjarne Stroustrup)
More information about the dm-crypt