Re: LUKS2 support for null/plaintext target

On 6 Dec 2019 16:10 -0700, from [email protected] (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 • [email protected]
 “Remember when, on the Internet, nobody cared that you were a dog?”

_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt