On 6 Dec 2019 16:10 -0700, from lists@xxxxxxxxxxxxxxxxx (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@xxxxxxxxxxx “Remember when, on the Internet, nobody cared that you were a dog?” _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
