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 8WUZrDtSp3Fb for ; Wed, 15 Jan 2014 21:27:10 +0100 (CET) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Wed, 15 Jan 2014 21:27:10 +0100 (CET) Received: by mail-ea0-f170.google.com with SMTP id k10so725071eaj.1 for ; Wed, 15 Jan 2014 12:27:10 -0800 (PST) Received: from [192.168.2.18] (56.157.broadband5.iol.cz. [88.100.157.56]) by mx.google.com with ESMTPSA id 1sm13067688eeg.4.2014.01.15.12.27.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 12:27:09 -0800 (PST) Message-ID: <52D6EF1B.4020206@gmail.com> Date: Wed, 15 Jan 2014 21:27:07 +0100 From: Milan Broz MIME-Version: 1.0 References: <638F1A81-8F17-4E18-8993-7F848EA84F08@offensive-security.com> <20140114043042.GA15870@tansi.org> In-Reply-To: <20140114043042.GA15870@tansi.org> 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: dm-crypt@saout.de On 01/14/2014 05:30 AM, Arno Wagner wrote: > I think that in your scenario, "nuke" does not have any real > advantages over just not having the passphrase, and that one > is dangerous. Well, this idea is not new and I responded very similar months ago. http://code.google.com/p/cryptsetup/issues/detail?id=110#c1 But seems there is a lot of people in disagreement. I was quite surprised that most of people from our university security&crypto lab I met today and asked (to have some other opinions) said that despite "nuke password" has very limited use it is worth to have something like that... Sigh... :) But what I really want to avoid is that every distribution will add some random patches implementing something like this. It is perhaps better to implement and document this upstream. Anyway, you have to manually create such key. And cryptsetup never blocked you from shooting yourself in the foot if you really want. ... >From the pure technical POV (ignoring the use case discussion) https://raw.github.com/offensive-security/cryptsetup-nuke-keys/master/cryptsetup_1.6.1+nuke_keys.diff The principle is ok (it should be implemented on libcryptsetup level, so it works from every GUI extension etc). But I do not like the details: - we do not need additional luksAddNuke command, switch like "--use-slot-destruction-key" option to luksAddKey is enough - I do not like that special key is all zeroes. (This is sometimes used for testing etc). IMHO "nuke key" should be linked to exact header key (if you copy this keyslot area to another LUKS header it should not work there). To be extra paranoid, I think nuke key should be randomized. This can be done e.g. if nuke key contains some salt, part of real key fingerprint (from LUKS header) and some magic string. - I think that "nuke" keyslot should remain active. (not really sure about this) Opinions? Thanks, Milan