[dm-crypt] LUKS2 support for null/plaintext target

[dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy]

Hi,

I'm wondering if it's possible, or LUKS2 could be extended, to support
an non-encrypted target. That is, the virtual device and backing
device would contain the same information.

The use case is to make it possible for software installers to make
future encryption possible for a volume without need to
repartition/reformat.

Thanks,

-- 
Chris Murphy

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Michael Kjörling]

On 6 Dec 2019 16:10 -0700, from lists@colorremedies.com (Chris Murphy):
> The use case is to make it possible for software installers to make
> future encryption possible for a volume without need to
> repartition/reformat.

Wouldn't a normal LUKS container with an empty passphrase meet that
use case just as well?

With an empty passphrase (and possibly a low iteration count; I don't
know if that would matter or not in the specific case of an empty
passphrase, and it certainly wouldn't matter _in practice_), you're
_effectively_ not gaining any protection from the encryption. To gain
protection would involve setting a passphrase, deleting the
empty-passphrase key slot, and reencrypting the volume with a new
master key (which would also invalidate any potentially-leaked header
copies). In other words, about the same as in your proposed scenario.

Especially if the empty-passphrase keyslot is in a well-known
location, that whole process could easily be automated.

The only real difference would seem to me to be that with actual
encryption, you're paying the performance penalty for the encryption
even though you aren't gaining any security benefit from doing the
encryption (and decryption), which would be less of case with a null
cipher. But if you're on a system today where that matters to any
significant degree, it seems unlikely you'll want to add encryption
later, so that appears to me to be somewhat of a draw.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy]

On Sat, Dec 7, 2019 at 2:42 AM Michael Kjörling <michael@kjorling.se> wrote:
>
> On 6 Dec 2019 16:10 -0700, from lists@colorremedies.com (Chris Murphy):
> > The use case is to make it possible for software installers to make
> > future encryption possible for a volume without need to
> > repartition/reformat.
>
> Wouldn't a normal LUKS container with an empty passphrase meet that
> use case just as well?

Maybe?

The main idea is to enable a distro/OS installer to avoid
interactivity and UI for setting up encrypted volumes, but make it
possible to setup and enabled post-install.

I haven't tried it, but does 'cryptsetup luksFormat' permit an empty
passphrase? And if it's empty, would 'cryptsetup luksOpen' open it
without a passphrase or keyfile?


-- 
Chris Murphy

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Milan Broz]

Hi,

On 07/12/2019 00:10, Chris Murphy wrote:
> I'm wondering if it's possible, or LUKS2 could be extended, to support
> an non-encrypted target. That is, the virtual device and backing
> device would contain the same information.

(You are not the first one asking for support for this option.)

In fact, the support is already there. But I am reluctant to officially
support it for a very long time, because it would be super confusing
for users (We have LUKS, but actually no encryption?!)

So, the first method:
you can always use cipher_null (and you must use empty passphrase in this case).
That variant should work already and it is intended for debugging/measuring dm-crypt
layer overhead (dm-crypt is used, but with the null cipher).

The second variant is to directly use dm-linear target instead of dm-crypt,
and it is already used during online (re)encryption in one phase - when adding
encryption to not yet encrypted device.
You cannot format such a device initially this way.

It is not so complicated to add support for this to format operation,
but ... I am still not sure. Any comments?

Milan

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy]

On Fri, Dec 13, 2019 at 7:59 AM Milan Broz <gmazyland@gmail.com> wrote:
>
> Hi,
>
> On 07/12/2019 00:10, Chris Murphy wrote:
> > I'm wondering if it's possible, or LUKS2 could be extended, to support
> > an non-encrypted target. That is, the virtual device and backing
> > device would contain the same information.
>
> (You are not the first one asking for support for this option.)
>
> In fact, the support is already there. But I am reluctant to officially
> support it for a very long time, because it would be super confusing
> for users (We have LUKS, but actually no encryption?!)

I agree there is potential for confusion. And it might be out of scope for LUKS.

When I do:
# blkid

I see a partition is TYPE="crypto_LUKS"  and that's a fairly difficult
statement of fact to overcome with a "yeah but it really isn't crypto,
you should have run this other command that would tell you that".

There is a valid argument that the crypto_LUKS signature should be
trusted to mean the contents are in fact ciphertext,, and not
pseudo-ciphertext trivially unlocked.


> So, the first method:
> you can always use cipher_null (and you must use empty passphrase in this case).
> That variant should work already and it is intended for debugging/measuring dm-crypt
> layer overhead (dm-crypt is used, but with the null cipher).
>
> The second variant is to directly use dm-linear target instead of dm-crypt,
> and it is already used during online (re)encryption in one phase - when adding
> encryption to not yet encrypted device.
> You cannot format such a device initially this way.
>
> It is not so complicated to add support for this to format operation,
> but ... I am still not sure. Any comments?

In some sense the feature request is trying to make LUKS deal with two
difficulties:
1.  producing a standard everyone can agree on, because if LUKS
doesn't do it, would anyone else follow it?
2.  adding the necessary free space in front of the partition to be
encrypted, the area that would be used for the LUKS header and padding

The gotcha with 2. without LUKS taking on this role, is how ugly it
ends up looking depending on what partition scheme is being used:
a. GPT only: create an empty partition ~16MB, immediately before the
intended plaintext partition that will be later converted (encrypted).
Maybe it gets a unique magic, or a new partition type GUID, that
describe it as "empty but intended for future LUKS-based encryption of
the partition that follows"

b. LVM LV? No idea.
c. MBR? Similar to GPT?
d. Files used on loop? Always use GPT, and follow the GPT guideline above.



-- 
Chris Murphy

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Arno Wagner]

On Fri, Dec 13, 2019 at 19:54:48 CET, Chris Murphy wrote:
> On Fri, Dec 13, 2019 at 7:59 AM Milan Broz <gmazyland@gmail.com> wrote:
> >
> > Hi,
> >
> > On 07/12/2019 00:10, Chris Murphy wrote:
> > > I'm wondering if it's possible, or LUKS2 could be extended, to support
> > > an non-encrypted target. That is, the virtual device and backing
> > > device would contain the same information.
> >
> > (You are not the first one asking for support for this option.)
> >
> > In fact, the support is already there. But I am reluctant to officially
> > support it for a very long time, because it would be super confusing
> > for users (We have LUKS, but actually no encryption?!)
> 
> I agree there is potential for confusion. And it might be out of scope for LUKS.
> 
> When I do:
> # blkid
> 
> I see a partition is TYPE="crypto_LUKS"  and that's a fairly difficult
> statement of fact to overcome with a "yeah but it really isn't crypto,
> you should have run this other command that would tell you that".
> 
> There is a valid argument that the crypto_LUKS signature should be
> trusted to mean the contents are in fact ciphertext,, and not
> pseudo-ciphertext trivially unlocked.

Very much so. Security is hard enough if KISS is used everywhere.
When KISS is violated, things become impossible to understand
and manage.

Most successful engineering these days is not only smart
people doing things, it is smart people with a lot of experience
following KISS and hence actually understanding what they are 
doing.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Robert Nichols]

On 12/13/19 8:59 AM, Milan Broz wrote:
> Hi,
> 
> On 07/12/2019 00:10, Chris Murphy wrote:
>> I'm wondering if it's possible, or LUKS2 could be extended, to support
>> an non-encrypted target. That is, the virtual device and backing
>> device would contain the same information.
> 
> (You are not the first one asking for support for this option.)
> 
> In fact, the support is already there. But I am reluctant to officially
> support it for a very long time, because it would be super confusing
> for users (We have LUKS, but actually no encryption?!)

How about using real encryption but use /dev/null as the key-file?
(Just a thought.)

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Arno Wagner]

On Sat, Dec 14, 2019 at 05:28:31 CET, Robert Nichols wrote:
> On 12/13/19 8:59 AM, Milan Broz wrote:
> >Hi,
> >
> >On 07/12/2019 00:10, Chris Murphy wrote:
> >>I'm wondering if it's possible, or LUKS2 could be extended, to support
> >>an non-encrypted target. That is, the virtual device and backing
> >>device would contain the same information.
> >
> >(You are not the first one asking for support for this option.)
> >
> >In fact, the support is already there. But I am reluctant to officially
> >support it for a very long time, because it would be super confusing
> >for users (We have LUKS, but actually no encryption?!)
> 
> How about using real encryption but use /dev/null as the key-file?
> (Just a thought.)

I can see some nice failure modes with that, e.g. with accidentally
empty key files. 

I am also not sure what the use-case of the whole thing is
besides benchmarking and debugging as Milan said.

If you want to put evertyhing in place, but do not encrypt (yet) 
so you can just encrypt data in place later, this may be the wrong 
approach. I reccomend (and I think that is in the FAQ) to do a 
backup, wipe the data and make a LUKS container and then to restore 
that backup. Doing this without backup is dangerous anyways.

I think this may not have a good solution and we should default to
"secure" here. There are far too many security issues today that
come from people having selected "convenient" instead. Having some
way to do this that is not too convenient or obvious is fine.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy]

On Sat, Dec 14, 2019 at 7:45 AM Arno Wagner <arno@wagner.name> wrote:
>
> On Sat, Dec 14, 2019 at 05:28:31 CET, Robert Nichols wrote:
> > On 12/13/19 8:59 AM, Milan Broz wrote:
> > >Hi,
> > >
> > >On 07/12/2019 00:10, Chris Murphy wrote:
> > >>I'm wondering if it's possible, or LUKS2 could be extended, to support
> > >>an non-encrypted target. That is, the virtual device and backing
> > >>device would contain the same information.
> > >
> > >(You are not the first one asking for support for this option.)
> > >
> > >In fact, the support is already there. But I am reluctant to officially
> > >support it for a very long time, because it would be super confusing
> > >for users (We have LUKS, but actually no encryption?!)
> >
> > How about using real encryption but use /dev/null as the key-file?
> > (Just a thought.)
>
> I can see some nice failure modes with that, e.g. with accidentally
> empty key files.
>
> I am also not sure what the use-case of the whole thing is
> besides benchmarking and debugging as Milan said.
>
> If you want to put evertyhing in place, but do not encrypt (yet)
> so you can just encrypt data in place later, this may be the wrong
> approach. I reccomend (and I think that is in the FAQ) to do a
> backup, wipe the data and make a LUKS container and then to restore
> that backup. Doing this without backup is dangerous anyways.
>
> I think this may not have a good solution and we should default to
> "secure" here. There are far too many security issues today that
> come from people having selected "convenient" instead. Having some
> way to do this that is not too convenient or obvious is fine.

I don't know how it works with APFS (Apple File System) today, but up
until a couple years ago when Apple was still using JHFS+ and Core
Storage (their logical volume manager, with nearly the same
terminology as LVM), they had a live migration between unencrypted
(default installations) and encrypted. The user could even shutdown
and reboot during the conversion.

Based on observation, not any detailed analysis, the original state
out of the box has no encryption, and no Core Storage. It's a plain
GPT partition, using an HFS+ type code, and an ordinary journaled HFS+
volume. Upon enabling encryption, I surmise based on the before,
during, and after states on disk, that the HFS+ volume is slightly
shrunk (perhaps ~100MB, I'm guessing based on years of memory recall
here so take it with a grain of salt), and a bunch of Core Storage
metadata is written in that space, the original partition is changed
into a Core Storage partition in the GPT, while also presumably
becoming a PV (physical volume). And the conversion is maybe something
like a pvmove --atomic where the unencrypted extents are encrypted and
written elsewhere, while continuously expanding the encrypted PV and
shrinking the encrypted one.

From a user perspective, they're informed the encryption conversion
status is progressing with some time estimate to completion. The
before state on disk is clearly not encrypted, and the conversion
state is both in the GUI and CLI commands, also clearly stated to be
in a state of conversion and also it indicates which direction the
conversion is happening: encrypting or decrypting, since it's possible
to completely reverse this. Also, while they have all the same PV, VG,
LV terms, they also have an LF (logical family) layer which is
functionally inserting a LUKS layer as an attribute to an LV. i.e.
encryption is an integrated function of Core Storage.

So that's as a point of comparison what I think people are after is
that kind of use case, where LUKS2 already offers a live
re-encryption, but not an easy way to opt into it if it's not already
encrypted. You'd have to do a monolithic, offline, backup, setup
encryption, and restore. It's a bit tedious and requires some
expertise to do that, rather than the experts inventing a thing so
users can just push a button. The more regular users are left out of
this, I think the better, not merely for their convenience, but so
that they aren't f'g things up. A huge amount of data loss is user
induced.

I'm certainly on board the argument of keeping things simple as it
pertains to the LUKS2 format, and not conflate either
plaintext/pseudo-ciphertext with a volume that has metadata suggesting
very clearly it's ciphertext. But I'm likewise not on board with the
idea of avoiding user convenience, because that is when they make
mistakes. And if it's left to people only a little more sophisticated
than I am to invent something, that's when security mistakes get made,
somehow having left some unencrypted residue behind or  otherwise
leaked some information.

The impetus behind an Apple or Microsoft doing things this way, of
course they don't want users having to do a monolithic backup and
restore offline to get to an encrypted state. Users would sooner do
without it. And they don't want to recommend a reinstallation of the
OS to get there either for the same reason. Whereas on most Linux
distros this question is asked at install time. But that's often not
when the user has thought about whether or not that applies to their
use case, and opts for no encryption, and later realizing that their
chance is lost with a high burden to encrypt, they forego it.

And now some distributions either default to encryption enabled, or
are discussing it, with various degrees of consequences (the keyboard
layout problems, and whether the LUKS passphrase really is properly
considered user domain at all).

-- 
Chris Murphy

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Jordan Glover]

I think encrypting previously unencrypted data on the same disk
doesn't guarantee that old data won't be recoverable especially
on ssd/nvme which are ubiquitous today. Officially supporting
such case on LUKS will give users false sense of security of
their data.

Jordan

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Arno Wagner]

Good point. See also FAQ Item 5.19.

While a false sense of security is great for marketing,
I agree that we should avoid it.

Regards,
Arno


On Sun, Dec 15, 2019 at 18:51:00 CET, Jordan Glover wrote:
> I think encrypting previously unencrypted data on the same disk
> doesn't guarantee that old data won't be recoverable especially
> on ssd/nvme which are ubiquitous today. Officially supporting
> such case on LUKS will give users false sense of security of
> their data.
> 
> Jordan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy]

On Sun, Dec 15, 2019 at 10:51 AM Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
>
> I think encrypting previously unencrypted data on the same disk
> doesn't guarantee that old data won't be recoverable especially
> on ssd/nvme which are ubiquitous today. Officially supporting
> such case on LUKS will give users false sense of security of
> their data.

This problem exists even in the backup and restore to LUKS encrypted
volume case. In fact it's less reliable because there's no assurance
with backup->restore method that all previously occupied LBAs are
overwritten, whereas an inplace conversion can assure that all LBAs in
the previous range are read and encrypted. It's a matter of
implementation, there's the potential for false sense of security
regardless.



-- 
Chris Murphy

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Jordan Glover]

On Sunday, December 15, 2019 8:49 PM, Chris Murphy <lists@colorremedies.com> wrote:

> On Sun, Dec 15, 2019 at 10:51 AM Jordan Glover
> Golden_Miller83@protonmail.ch wrote:
>
> > I think encrypting previously unencrypted data on the same disk
> > doesn't guarantee that old data won't be recoverable especially
> > on ssd/nvme which are ubiquitous today. Officially supporting
> > such case on LUKS will give users false sense of security of
> > their data.
>
> This problem exists even in the backup and restore to LUKS encrypted
> volume case. In fact it's less reliable because there's no assurance
> with backup->restore method that all previously occupied LBAs are
>
> overwritten, whereas an inplace conversion can assure that all LBAs in
> the previous range are read and encrypted. It's a matter of
> implementation, there's the potential for false sense of security
> regardless.
>
> Chris Murphy

AFAIK simply overwriting data isn't reliable method for cleaning ssd/nvme.
For those either ATA SECURE ERASE[1] or blkdiscard[2] should be used.

Unless I'm mistaken, inplace conversion does neither while user can run
them manually during backup/restore.

[1] https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
[2] http://man7.org/linux/man-pages/man8/blkdiscard.8.html

Jordan

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy]

On Mon, Dec 16, 2019 at 10:08 AM Jordan Glover
<Golden_Miller83@protonmail.ch> wrote:
>
> On Sunday, December 15, 2019 8:49 PM, Chris Murphy <lists@colorremedies.com> wrote:
>
> > On Sun, Dec 15, 2019 at 10:51 AM Jordan Glover
> > Golden_Miller83@protonmail.ch wrote:
> >
> > > I think encrypting previously unencrypted data on the same disk
> > > doesn't guarantee that old data won't be recoverable especially
> > > on ssd/nvme which are ubiquitous today. Officially supporting
> > > such case on LUKS will give users false sense of security of
> > > their data.
> >
> > This problem exists even in the backup and restore to LUKS encrypted
> > volume case. In fact it's less reliable because there's no assurance
> > with backup->restore method that all previously occupied LBAs are
> >
> > overwritten, whereas an inplace conversion can assure that all LBAs in
> > the previous range are read and encrypted. It's a matter of
> > implementation, there's the potential for false sense of security
> > regardless.
> >
> > Chris Murphy
>
> AFAIK simply overwriting data isn't reliable method for cleaning ssd/nvme.
> For those either ATA SECURE ERASE[1] or blkdiscard[2] should be used.
>
> Unless I'm mistaken, inplace conversion does neither while user can run
> them manually during backup/restore.

Without testing, which would be make/model/firmware specific, it's not
certain what really happens on flash memory chips themselves. ATA
Secure Erase is probably the better recommendation but as both
ultimately depend on drive firmware to fulfill the operation, it's
really a big *shrug* and therefore I reject the idea that there is a
clear line in the sand. It should be true and probably is true that
Secure Erase Enhanced or Sanitize are better than blkdiscard. But if
it's uncertain, on what basis is a line drawn?  Upstreams can state
the facts including the unknowns, and help user and distros draw their
own line.

But consider that as a direct consequence of the burden to
backup->luksFormat>restore, quite a lot of users opt out of encryption
entirely. The point of in-place conversion isn't perfect security.
It's to get more users to opt in, by reducing the penalty of opting
in.

False sense of security? We have this problem already with cryptsetup
--allow-discards leaking fs specific locality in combination with
fstrim. And fscrypt() leaks quite a lot of metadata. And the ATA spec
allows reserve and overprovision areas to not be erased with Secure
Erase, where either Secure Erase Enhanced and Sanitize should cover
those areas.

In place conversion can be better supported in more sophisticated
environments. Linux installers are already overly complicated and soak
limited resources maintaining them  Opting into encryption right now
essentially requires either installer support or the burden of backup
restore. That's not great choices. And what installers provide an ATA
Secure Erase or Sanitize option? I don't know of any.

Conversely, Windows and macOS use comparatively brain dead installers
(very simplistic UI, perhaps a few choices at most, pretty much
amounting to point at a target and push a button). Easy to install.
Easy to make the encryption decision later without the penalty of
backup restore. Perfectly secure encryption? I don't know. But the
barrier to entry is low.

It is a very different problem where to find the resources to build
in-place conversion. But I think it's unwittingly asking more users to
forgo encryption at all to argue against it on the basis that it's
somehow a significant security risk. How many hours, days or weeks of
typical usage do you think takes before all cells have either been
erased or overwritten by encrypted data? There is interim exposure,
that some use case will care about, but some won't. And that might be
more useful in assessing a personal line in the sand than
categorically saying in-place conversion gives a false sense of
security.


-- 
Chris Murphy

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Arno Wagner]

On Mon, Dec 16, 2019 at 19:24:33 CET, Chris Murphy wrote:
[...]
> But consider that as a direct consequence of the burden to
> backup->luksFormat>restore, quite a lot of users opt out of encryption
> entirely. The point of in-place conversion isn't perfect security.
> It's to get more users to opt in, by reducing the penalty of opting
> in.

But why would you _want_ users to "opt in"? It seems like entirely
the wrong thing to do to me. First consider that the users 
you are talking about do not have backups. Hence their data must
be basically worthless anyways! Second, their data is so little
in need of protection that something as simple and as a backup  
already makes them do without encryption. Hence their data must
actually not be sensitive in any way!

Given these two things, why on earth do you want these people
to use encryption?

Security comes at a price. That price has to be paid. 
No price - no security. There is _no_ way to fix this and trying 
to do so only does damage to the user by making things too complex
for them to handle.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy]

On Mon, Dec 16, 2019 at 11:52 AM Arno Wagner <arno@wagner.name> wrote:
>
> On Mon, Dec 16, 2019 at 19:24:33 CET, Chris Murphy wrote:
> [...]
> > But consider that as a direct consequence of the burden to
> > backup->luksFormat>restore, quite a lot of users opt out of encryption
> > entirely. The point of in-place conversion isn't perfect security.
> > It's to get more users to opt in, by reducing the penalty of opting
> > in.
>
> But why would you _want_ users to "opt in"? It seems like entirely
> the wrong thing to do to me. First consider that the users
> you are talking about do not have backups. Hence their data must
> be basically worthless anyways!

First, this is a distraction and not relevant. It conflats
confidentiality with integrity/availability of the data. That the data
should be private/remain confidential is not related to it's long term
value.

Second, blkdiscard and fstrim can merely flag cells for erasure, or
merely dereference LBAs. No assurance the cells are actually erased or
when they will be erased. It's the same as the firmware passively
determining cells can be marked for erasure upon LBA overwrite of an
in-place conversion.

Is it your position that only Security Erase, Security Erase Enhanced,
or Sanitize avoid giving the user a false sense of security? In which
case, now the procedure requires a complete wipe of the drive. And
that means a fully offline process to conduct the restore until it is
complete during which time the system is not usable. And it's extra
burdensome for dual boot users, who must do two full reinstallations
and restores of those two operating systems.

>Second, their data is so little
> in need of protection that something as simple and as a backup
> already makes them do without encryption. Hence their data must
> actually not be sensitive in any way!

I reject the premise entirely. And it ignores users who have done a
backup, who still have a significantly greater burden put on them
through esoteric processes necessary to do encryption after the fact,
and a monolithic restore from backup which prevents them from working
until the restore is complete. That is not the case with in-place
conversion - the system is completely transparently usable the entire
time including reboots and shutdowns.

> Given these two things, why on earth do you want these people
> to use encryption?

I think these are weak arguments, in addition to wholesale ignoring
users who do backup who still have an unreasonable burden put on them
by existing choices: install time encryption or post-install partition
ninja and offline restore.

The vastly stronger argument is: this is really hard to do and we
don't want to do it.

Papering over that with unpersuasive security concerns, and making
assumptions about whether users backup or not, doesn't progress the
conversation.

> Security comes at a price. That price has to be paid.
> No price - no security. There is _no_ way to fix this and trying
> to do so only does damage to the user by making things too complex
> for them to handle.

The backup restore proposal is too complex, it's why users don't opt
in now. It's why alternatives are being explored by downstreams.

The argument that the user is at greater risk with an in-place
conversion than backup restore, neither depending on prior Secure
Erase or Sanitize but only depending on trim/discard, is not
persuasive. Such preparation is not built-in for any distro installer
with which I'm familiar, not even as an option let alone by default.
Secure Erase is esoteric knowledge. I would be surprised if 1 in 1000
users has heard of it.


-- 
Chris Murphy

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Arno Wagner]

On Mon, Dec 16, 2019 at 21:46:40 CET, Chris Murphy wrote:
> On Mon, Dec 16, 2019 at 11:52 AM Arno Wagner <arno@wagner.name> wrote:
> >
> > On Mon, Dec 16, 2019 at 19:24:33 CET, Chris Murphy wrote:
> > [...]
> > > But consider that as a direct consequence of the burden to
> > > backup->luksFormat>restore, quite a lot of users opt out of encryption
> > > entirely. The point of in-place conversion isn't perfect security.
> > > It's to get more users to opt in, by reducing the penalty of opting
> > > in.
> >
> > But why would you _want_ users to "opt in"? It seems like entirely
> > the wrong thing to do to me. First consider that the users
> > you are talking about do not have backups. Hence their data must
> > be basically worthless anyways!
> 
> First, this is a distraction and not relevant. It conflats
> confidentiality with integrity/availability of the data. That the data
> should be private/remain confidential is not related to it's long term
> value.

It is related to whether they have a backup procedure in place or not.
If you find that irrelevant, then I really cannot help you. 
Doing any kind of partition or filesystem manipulation without
a current, good backup is foolish at best and asking for data loss
at worst. And no, I am not open to debate on this.

> Second, blkdiscard and fstrim can merely flag cells for erasure, or
> merely dereference LBAs. No assurance the cells are actually erased or
> when they will be erased. It's the same as the firmware passively
> determining cells can be marked for erasure upon LBA overwrite of an
> in-place conversion.
> 
> Is it your position that only Security Erase, Security Erase Enhanced,
> or Sanitize avoid giving the user a false sense of security? In which
> case, now the procedure requires a complete wipe of the drive. And
> that means a fully offline process to conduct the restore until it is
> complete during which time the system is not usable. And it's extra
> burdensome for dual boot users, who must do two full reinstallations
> and restores of those two operating systems.

Who are you answering to here? _My_ position is that the only
way to securely erase an SSD is physical destruction.

> >Second, their data is so little
> > in need of protection that something as simple and as a backup
> > already makes them do without encryption. Hence their data must
> > actually not be sensitive in any way!
> 
> I reject the premise entirely. 

And I reject your rejection entirely as well. It seems to me
_you_ want to push something on users that they do not actually 
want or need. And you have presented exactly zero good arguments
so far why people should encrypt.

> And it ignores users who have done a
> backup, who still have a significantly greater burden put on them
> through esoteric processes necessary to do encryption after the fact,
> and a monolithic restore from backup which prevents them from working
> until the restore is complete. That is not the case with in-place
> conversion - the system is completely transparently usable the entire
> time including reboots and shutdowns.

Excuse me? Since when is doing a backup and restore in any way
"esoteric"? How much experience do you have with this "computing"
thing? 

Also, what makes you think that in-place conversion can easily
reach the level of resilience you assume it has? Getting there
takes a _lot_ of testing and very defensive and careful coding
and it may well have to include other layers than the one
LUKS resides in. 

> > Given these two things, why on earth do you want these people
> > to use encryption?
> 
> I think these are weak arguments, 

Do you have any actual argument here? Because it does not seem you
have any...

> in addition to wholesale ignoring
> users who do backup who still have an unreasonable burden put on them
> by existing choices: install time encryption or post-install partition
> ninja and offline restore.

How on earth can you call this an "unreasonable burden"? 

> The vastly stronger argument is: this is really hard to do and we
> don't want to do it.

Ok, I see you are not actually interested in any facts here,
you just want to push your view. 
Even minimal standards of competent private IT operation do 
include backup and restore as standard operations.
 
> Papering over that with unpersuasive security concerns, and making
> assumptions about whether users backup or not, doesn't progress the
> conversation.

As does allowing exactly no progress except in the direction
you are trying to force. And please stop the cheap propaganda
language. It is insulting. And it convinces nobody.
 
> > Security comes at a price. That price has to be paid.
> > No price - no security. There is _no_ way to fix this and trying
> > to do so only does damage to the user by making things too complex
> > for them to handle.
> 
> The backup restore proposal is too complex, it's why users don't opt
> in now. It's why alternatives are being explored by downstreams.

Empty, unfounded claim. Why again do you want users to "opt in"?
Oh, right, You did not say.  

> The argument that the user is at greater risk with an in-place
> conversion than backup restore, neither depending on prior Secure
> Erase or Sanitize but only depending on trim/discard, is not
> persuasive. 

I did not make that argument.

> Such preparation is not built-in for any distro installer
> with which I'm familiar, not even as an option let alone by default.
> Secure Erase is esoteric knowledge. I would be surprised if 1 in 1000
> users has heard of it.

And that is why I recommend physical destruction instead.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Michael Kjörling]

On 16 Dec 2019 11:24 -0700, from lists@colorremedies.com (Chris Murphy):
> In place conversion can be better supported in more sophisticated
> environments. Linux installers are already overly complicated and soak
> limited resources maintaining them  Opting into encryption right now
> essentially requires either installer support or the burden of backup
> restore. That's not great choices. And what installers provide an ATA
> Secure Erase or Sanitize option? I don't know of any.

I don't know about current Mac OS X, but Windows has it far easier.
They only support two (three if you count ReFS) file systems, and IIRC
only NTFS can be used on the system partition. An in-place conversion
from unencrypted to encrypted can be developed and tested _relatively_
painlessly when you basically only need to support _one_ format within
the encrypted container, whether the container format is called LUKS
or BitLocker or something else.

Contrast this to LUKS on Linux, which can be used with anything from
no file system at all to file systems you might not have even heard
of. Okay, it's probably fairly simple to do an in-place conversion of
a container that contains just an ext4 file system, and it's probably
a reasonable first step since ext4 is so commonly used. What if what's
in the container is a part of a volume group? What if it's a part of a
MD RAID array? What if it's a part of a Btrfs file system? A part of a
ZFS vdev? (In the case of the latter two, either mirrored or
RAID5/6-esque.) Or XFS? How about a squashfs? And that's just to list
a few. And that's before we consider people potentially doing crazy
things like putting a LUKS container inside a LUKS container. Or
people who still use LILO.

Sure, for some of those, you might say "we don't need to cater to
those cases for online migration from unencrypted to encrypted". But
that, too, is drawing a largely arbitrary line somewhere. What says
one thing goes on one side of that line, and another goes on the other
side, except someone's say-so?

The seemingly obvious solution indeed is to have an unencrypted LUKS
container pre-prepared, at which point it's possible to do at least an
offline reencryption in-place with current tools. But then the issue
indeed becomes that you've got metadata that indicates you've got
something which is normally encrypted, except in this one case where
it isn't. That seems likely to trip at least a moderate number of
people up because they'd look, see LUKS, and conclude that their data
is protected, when in fact it isn't. Every tool that identifies
something as a LUKS container would, at a minimum, need to peek into
it to identify the "unencrypted LUKS" special case to protect against
this. Which again is much easier when you control the entire operating
system, including the system software.


> Conversely, Windows and macOS use comparatively brain dead installers
> (very simplistic UI, perhaps a few choices at most, pretty much
> amounting to point at a target and push a button). Easy to install.
> Easy to make the encryption decision later without the penalty of
> backup restore. Perfectly secure encryption? I don't know. But the
> barrier to entry is low.

I don't think I'd call the Windows installer "brain dead". Simplified,
yes, but that's not the same thing. They hide a lot of the complexity
which of course also means that when you _do_ have a legitimate need
to do something out of the ordinary, you generally can't.

There are Linux distributions with installers that aren't a great deal
more complex than the Windows installer, especially if you go for the
"simple" installation. Of course, if you take a distribution that's
already geared toward power users, and use its advanced installation
mode, you're going to be presented with a lot of choices, but only
because you asked to be.

As for backups; encryption increases the risk of data loss. I don't
know off hand how long you've been on the list, but it happens usually
a few times per year that someone asks how to recover their data
because they can't open the LUKS container normally. _People in
general don't have backups. My experience is that even fairly
technically savvy people often don't have backups._ By adding
encryption, especially with something like LUKS' anti-forensic
properties, you (general "you") are increasing the risk of data loss
quite significantly, because you go from what would otherwise be a
trivial problem to making the same situation a catastrophic problem.
I'm not a fan of scary UI messages, but I do feel that that _should_
come with big warning labels, so that the user is at least _aware_ of
what they are doing and its implications.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
 “Remember when, on the Internet, nobody cared that you were a dog?”

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Chris Murphy]

On Mon, Dec 16, 2019 at 2:36 PM Michael Kjörling <michael@kjorling.se> wrote:
>
> On 16 Dec 2019 11:24 -0700, from lists@colorremedies.com (Chris Murphy):
> > In place conversion can be better supported in more sophisticated
> > environments. Linux installers are already overly complicated and soak
> > limited resources maintaining them  Opting into encryption right now
> > essentially requires either installer support or the burden of backup
> > restore. That's not great choices. And what installers provide an ATA
> > Secure Erase or Sanitize option? I don't know of any.
>
> I don't know about current Mac OS X, but Windows has it far easier.
> They only support two (three if you count ReFS) file systems, and IIRC
> only NTFS can be used on the system partition. An in-place conversion
> from unencrypted to encrypted can be developed and tested _relatively_
> painlessly when you basically only need to support _one_ format within
> the encrypted container, whether the container format is called LUKS
> or BitLocker or something else.
>
> Contrast this to LUKS on Linux, which can be used with anything from
> no file system at all to file systems you might not have even heard
> of. Okay, it's probably fairly simple to do an in-place conversion of
> a container that contains just an ext4 file system, and it's probably
> a reasonable first step since ext4 is so commonly used. What if what's
> in the container is a part of a volume group? What if it's a part of a
> MD RAID array? What if it's a part of a Btrfs file system? A part of a
> ZFS vdev? (In the case of the latter two, either mirrored or
> RAID5/6-esque.) Or XFS? How about a squashfs? And that's just to list
> a few. And that's before we consider people potentially doing crazy
> things like putting a LUKS container inside a LUKS container. Or
> people who still use LILO.

I fully agree with all of these as possibly insurmountable hurdles,
and the ensuing liabilities to develop, test, and maintain it. It's
very much a exploded test matrix. These big companies have the luxury
of lots of money and edicts mandate very narrowed scope.

I can't argue with "it's too difficult to support it all as well as
fully prevent crazy things" and it very well may be that the interest
or even resource level isn't there to support subjectively narrowed
solutions. That's compatible with my previous email.


>
> Sure, for some of those, you might say "we don't need to cater to
> those cases for online migration from unencrypted to encrypted". But
> that, too, is drawing a largely arbitrary line somewhere. What says
> one thing goes on one side of that line, and another goes on the other
> side, except someone's say-so?

Resources. Interest. Expertise. The line is perhaps two parts
subjective, one part objective. There is nothing wrong with that. It's
not arbitrary or capricious.


> The seemingly obvious solution indeed is to have an unencrypted LUKS
> container pre-prepared, at which point it's possible to do at least an
> offline reencryption in-place with current tools. But then the issue
> indeed becomes that you've got metadata that indicates you've got
> something which is normally encrypted, except in this one case where
> it isn't. That seems likely to trip at least a moderate number of
> people up because they'd look, see LUKS, and conclude that their data
> is protected, when in fact it isn't. Every tool that identifies
> something as a LUKS container would, at a minimum, need to peek into
> it to identify the "unencrypted LUKS" special case to protect against
> this. Which again is much easier when you control the entire operating
> system, including the system software.

What about a totally different "dummy" LUKS format, that is a place
holder expressly for this purpose? Gets it's own magic, and libblkid
would know about it, and therefore there'd be no confusion or wrong
assumptions about it being encrypted? A "pre-gap" or "pre-partition"
in front of the file system? Would mount need to know how to deal with
it directly, or would it always need to be "opened" and the contained
file system presented as a dm block device?


> As for backups; encryption increases the risk of data loss. I don't
> know off hand how long you've been on the list, but it happens usually
> a few times per year that someone asks how to recover their data
> because they can't open the LUKS container normally.

Days, week. I saw one maybe minutes after my first post. I've been on
linux-raid, lvm, and Btrfs lists for years and I'm aware of the common
case of user induced data loss.

>_People in
> general don't have backups. My experience is that even fairly
> technically savvy people often don't have backups._ By adding
> encryption, especially with something like LUKS' anti-forensic
> properties, you (general "you") are increasing the risk of data loss
> quite significantly, because you go from what would otherwise be a
> trivial problem to making the same situation a catastrophic problem.
> I'm not a fan of scary UI messages, but I do feel that that _should_
> come with big warning labels, so that the user is at least _aware_ of
> what they are doing and its implications.

Yeah I consider it an unsolved problem in computer science generally;
if there is a false sense of security that has meaningful impact on
people's lives, it is the complacency of not knowing what to be
worried about and the disproportionate penalties that can just appear.
Maybe it's just early days of computing, we're still toddlers, we
still fall down and get hurt and all we can do is dust ourselves off
and be a little more careful next time.


-- 
Chris Murphy

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Jordan Glover]

On Monday, December 16, 2019 6:24 PM, Chris Murphy <lists@colorremedies.com> wrote:

> On Mon, Dec 16, 2019 at 10:08 AM Jordan Glover
> Golden_Miller83@protonmail.ch wrote:
>
> > On Sunday, December 15, 2019 8:49 PM, Chris Murphy lists@colorremedies.com wrote:
> >
> > > On Sun, Dec 15, 2019 at 10:51 AM Jordan Glover
> > > Golden_Miller83@protonmail.ch wrote:
> > >
> > > > I think encrypting previously unencrypted data on the same disk
> > > > doesn't guarantee that old data won't be recoverable especially
> > > > on ssd/nvme which are ubiquitous today. Officially supporting
> > > > such case on LUKS will give users false sense of security of
> > > > their data.
> > >
> > > This problem exists even in the backup and restore to LUKS encrypted
> > > volume case. In fact it's less reliable because there's no assurance
> > > with backup->restore method that all previously occupied LBAs are
> > > overwritten, whereas an inplace conversion can assure that all LBAs in
> > > the previous range are read and encrypted. It's a matter of
> > > implementation, there's the potential for false sense of security
> > > regardless.
> > > Chris Murphy
> >
> > AFAIK simply overwriting data isn't reliable method for cleaning ssd/nvme.
> > For those either ATA SECURE ERASE[1] or blkdiscard[2] should be used.
> > Unless I'm mistaken, inplace conversion does neither while user can run
> > them manually during backup/restore.
>
> Without testing, which would be make/model/firmware specific, it's not
> certain what really happens on flash memory chips themselves. ATA
> Secure Erase is probably the better recommendation but as both
> ultimately depend on drive firmware to fulfill the operation, it's
> really a big shrug and therefore I reject the idea that there is a
> clear line in the sand. It should be true and probably is true that
> Secure Erase Enhanced or Sanitize are better than blkdiscard. But if
> it's uncertain, on what basis is a line drawn? Upstreams can state
> the facts including the unknowns, and help user and distros draw their
> own line.
>

From my own testing I could trivially recover files after overwrite but
not after blkdiscard. I can't rule out that some hardware hackers can
recover data after blkdiscard or secure erase but for me the line in the
sand lies between hardware hackers and average Jane that uses google.

> But consider that as a direct consequence of the burden to
> backup->luksFormat>restore, quite a lot of users opt out of encryption
>
> entirely. The point of in-place conversion isn't perfect security.
> It's to get more users to opt in, by reducing the penalty of opting
> in.
>
> False sense of security? We have this problem already with cryptsetup
> --allow-discards leaking fs specific locality in combination with
> fstrim. And fscrypt() leaks quite a lot of metadata. And the ATA spec
> allows reserve and overprovision areas to not be erased with Secure
> Erase, where either Secure Erase Enhanced and Sanitize should cover
> those areas.
>

allow-discards downsides are in different league that recovering
unencrypted data. I believe users will be better off while not using
encryption and knowing that than using encryption in insecure way without
knowing that.

> In place conversion can be better supported in more sophisticated
> environments. Linux installers are already overly complicated and soak
> limited resources maintaining them Opting into encryption right now
> essentially requires either installer support or the burden of backup
> restore. That's not great choices. And what installers provide an ATA
> Secure Erase or Sanitize option? I don't know of any.
>
> Conversely, Windows and macOS use comparatively brain dead installers
> (very simplistic UI, perhaps a few choices at most, pretty much
> amounting to point at a target and push a button). Easy to install.
> Easy to make the encryption decision later without the penalty of
> backup restore. Perfectly secure encryption? I don't know. But the
> barrier to entry is low.
>

I believe referring to Windows as role example undermines your arguments
rather than making  them more compelling. Windows has history of "user
friendliness" like preferring hardware encryption which ended as security
failure:

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV180028

It also leverages beloved tpm module:

https://pulsesecurity.co.nz/articles/TPM-sniffing

Whatever windows do with encryption it's anti-pattern and cryptsetup should
stay away from that.

Even on linux the "user friendly" installers were storing luks key
in plaintext accessible to anyone:

https://calamares.io/calamares-3.2.11-is-out/

> It is a very different problem where to find the resources to build
> in-place conversion. But I think it's unwittingly asking more users to
> forgo encryption at all to argue against it on the basis that it's
> somehow a significant security risk. How many hours, days or weeks of
> typical usage do you think takes before all cells have either been
> erased or overwritten by encrypted data? There is interim exposure,
> that some use case will care about, but some won't. And that might be
> more useful in assessing a personal line in the sand than
> categorically saying in-place conversion gives a false sense of
> security.
>
> Chris Murphy

I agree that security is hard and users are unsophisticated but I'm not
convinced what you propose will help those people rather than hurt them.
It's easy to imagine that people will believe that their data is encrypted
after install if they use luks and miss the fact that some action is needed
to actually enable encryption.

Jordan

Re: [dm-crypt] LUKS2 support for null/plaintext target

[Arno Wagner]

On Tue, Dec 17, 2019 at 18:07:11 CET, Jordan Glover wrote:
> On Monday, December 16, 2019 6:24 PM, Chris Murphy <lists@colorremedies.com> wrote:
[...] 
> > It is a very different problem where to find the resources to build
> > in-place conversion. But I think it's unwittingly asking more users to
> > forgo encryption at all to argue against it on the basis that it's
> > somehow a significant security risk. How many hours, days or weeks of
> > typical usage do you think takes before all cells have either been
> > erased or overwritten by encrypted data? There is interim exposure,
> > that some use case will care about, but some won't. And that might be
> > more useful in assessing a personal line in the sand than
> > categorically saying in-place conversion gives a false sense of
> > security.
> >
> > Chris Murphy
> 
> I agree that security is hard and users are unsophisticated but I'm not
> convinced what you propose will help those people rather than hurt them.
> It's easy to imagine that people will believe that their data is encrypted
> after install if they use luks and miss the fact that some action is needed
> to actually enable encryption.
> 
> Jordan

I agree on that. And here we have a responsibility: It must be as
hard as possible to screw this up and the state things are in
must be as obvious as possible. It is better if getting encryption
requires some work and some reading, than if it is easy to mistake
the state of things and thinking you are secure when you are not.
That way, anybody that really cares will have encrytion and anybody
that finds this too much of a bother will not have encryption, but 
they will all know where they stand.

Also, I have absolutely no tolerance for the idea that everyting
with computers must be (apparently) easy and simple. We spend
years teching kids to learn how to read and write, but somehow
when using the most sophisticated tech the human race has ever 
made, everything must be a single click. 

That is obvious nonsense and catering to this mindset does damage. 
What should be be done instead is to make it as clear as possible 
that some things are hard to do, hard to understand and that there
is no replacement for finding out. That way, nobody will be fooled
into thinking things are easy that are not, just because they
have been designed to appear to be easy. You cannot make complicated
things simple. Complexity can be hidden but only in mature tech 
can it be removed. In computers (which are anything but mature)
you can only lie to the users, to their detriment.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier