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 rkL5RzfNw1UJ for ; Mon, 27 Jan 2014 13:44:48 +0100 (CET) Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.saout.de (Postfix) with ESMTP for ; Mon, 27 Jan 2014 13:44:47 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-44-24.dclient.hispeed.ch [77.57.44.24]) by v6.tansi.org (Postfix) with ESMTPA id 8006820DC23B for ; Mon, 27 Jan 2014 13:44:47 +0100 (CET) Date: Mon, 27 Jan 2014 13:44:46 +0100 From: Arno Wagner Message-ID: <20140127124446.GA17612@tansi.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62a688cb4fb5803b21139dcc03342e05@imap.steindlberger.de> Subject: Re: [dm-crypt] nuke password to delete luks header List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Mon, Jan 27, 2014 at 10:04:28 CET, Jonas Meurer wrote: > Am 2014-01-23 22:26, schrieb Milan Broz: > >Hi, > > > >as Arno said, let's split this to two parts. > > > >>1. Have a secure erase that is easy to use. [...] > >> > >>2. Have the option of unlocking a keyslot created with a specific > >> option to trigger the function implemented in 1. [...] [...] > 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. I think it should not ask for a password, but ask for confirmation, like having the user type "ERASE" in shell-interaction, unless -q/--batch-mode is given. The password would not protect better as a user that can run cryptsetup can also (but less intuitively) call luksFormat to erase the container. Incidentally, that means wrappers are already possible. (In fact, Ubuntu already demonstrated erase-on-install, abeit unintentionally, see FAQ Item 1.3.) A luksErase command is better, as it works cleaner, erasing is its primary purpose, not just a side-effect and it does not ask for a new password. > >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? ;) People making a mess of it? No. Otherwise you would have a really easy tool to force upstream to implement things. People making a mess of it is just a hint that things may be more complicated than they claim they are. A common occurence, especially with security functionality. 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