From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.saout.de ([127.0.0.1]) by localhost (mail.saout.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXcCwtg8QzVJ for ; Mon, 27 Jan 2014 21:30:12 +0100 (CET) Received: from mail-ee0-x232.google.com (mail-ee0-x232.google.com [IPv6:2a00:1450:4013:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Mon, 27 Jan 2014 21:30:12 +0100 (CET) Received: by mail-ee0-f50.google.com with SMTP id d17so2471147eek.37 for ; Mon, 27 Jan 2014 12:30:11 -0800 (PST) Message-ID: <52E6C1D0.1000508@gmail.com> Date: Mon, 27 Jan 2014 21:30:08 +0100 From: Milan Broz MIME-Version: 1.0 References: <638F1A81-8F17-4E18-8993-7F848EA84F08@offensive-security.com> <20140114043042.GA15870@tansi.org> <52D6EF1B.4020206@gmail.com> <52DEF745.5040507@freesources.org> <52E18912.7070808@gmail.com> <62a688cb4fb5803b21139dcc03342e05@imap.steindlberger.de> In-Reply-To: <62a688cb4fb5803b21139dcc03342e05@imap.steindlberger.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [dm-crypt] nuke password to delete luks header List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jonas Meurer , dm-crypt@saout.de On 01/27/2014 10:04 AM, Jonas Meurer wrote: >> For 2, (aka self destroy passphrase) - I tried to read the discussion >> again >> and I am really not convinced yet we want it. > > Do you intend to protect the erase feature by asking for a password? In > that > case it will be hard to build a nuke wrapper around 'cryptsetup erase'. > Especially if the nuke password should not reveal access to encrypted > data > and merely allow to erase LUKS header. No, only usual YES/no question should (will) be there (which can be switched off with batch -q option as in other commands). The luksKillSlot is doing exactly the same, just for one keyslot. Actually, it is just simple code as for all active keyslots: crypt_destroy_slot() >> BTW original patch is INCOMPLETE and DANGEROUS. >> >> (For example, did anyone think about cryptsetup-reencrypt? Guess what >> will >> happen if user try to *reencrypt* device with this destroy passphrase? >> Try it... or better not ;-) And there are more missing code which just >> do not convince me that it was properly thought-out work. > > Isn't that a good argument for implementing it properly upstream? ;) I think this argument was mentioned by me :) But I think we have found better way how to implement it without this feature. Avoiding upstream to become bloatware is also important ;-) ... > While I see your argument, reencryption takes a lot more time than using > a > nuke feature. Both features serve completely different purposes. Sure, it was just a complain about features importance... (And btw there is in git already function to change only header (hash) without reencrypting the whole device. This will be a workaround to solve bad gcrypt whirlpool case. Once gcrypt 1.6.1 is out...) ... > And if you merely want to destroy access to the data, overwriting it is > still > better than reencrypting, isn't it? Yes, and removing key with "erase" command should do the same quickly as well. Milan