From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from pio-pvt-msa1.bahnhof.se (pio-pvt-msa1.bahnhof.se [79.136.2.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Sat, 7 Dec 2019 10:39:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by pio-pvt-msa1.bahnhof.se (Postfix) with ESMTP id 7BA293F675 for ; Sat, 7 Dec 2019 10:39:19 +0100 (CET) Received: from pio-pvt-msa1.bahnhof.se ([127.0.0.1]) by localhost (pio-pvt-msa1.bahnhof.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALkzm0aWvXx5 for ; Sat, 7 Dec 2019 10:39:18 +0100 (CET) Received: from localhost (unknown [85.24.253.25]) (Authenticated sender: mc616801) by pio-pvt-msa1.bahnhof.se (Postfix) with ESMTPA id 319FA3F58A for ; Sat, 7 Dec 2019 10:39:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (Postfix) with ESMTPS id A7DD52E02C7 for ; Sat, 7 Dec 2019 10:39:17 +0100 (CET) Date: Sat, 7 Dec 2019 09:39:16 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [dm-crypt] LUKS2 support for null/plaintext target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de 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?”