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 VZ9--tiIBePP for ; Fri, 17 Jan 2014 15:32:25 +0100 (CET) Received: from mail01.freesources.org (mx01.freesources.org [80.237.252.132]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 17 Jan 2014 15:32:25 +0100 (CET) Received: from cb-hafen-75-68.rz.uni-frankfurt.de ([141.2.75.68]) by mail01.freesources.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1W4AT8-0007oI-4M for dm-crypt@saout.de; Fri, 17 Jan 2014 14:32:25 +0000 Message-ID: <52D93EF4.1070809@freesources.org> Date: Fri, 17 Jan 2014 15:32:20 +0100 From: Jonas Meurer MIME-Version: 1.0 References: <638F1A81-8F17-4E18-8993-7F848EA84F08@offensive-security.com> <20140114043042.GA15870@tansi.org> <52D6EF1B.4020206@gmail.com> <52D7AB5E.8020302@redhat.com> <52D833F1.5010205@gmail.com> <20140116201837.GA16656@citd.de> <52D9257E.6000906@freesources.org> <20140117131209.GA27651@tansi.org> In-Reply-To: <20140117131209.GA27651@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 Am 17.01.2014 14:12, schrieb Arno Wagner: > On Fri, Jan 17, 2014 at 13:43:42 CET, Jonas Meurer wrote: >> Am 16.01.2014 21:18, schrieb Matthias Schniedermeyer: >>> Meanwhile increasing the risk of everybody else, because once that >>> feature is a documented part of the system everybody will assume that >>> everybody will use it. Good look defending against a "Destruction of >>> Evidence" accusation, in case that happens in a situation with a LEO. >>> [...] >>> In short: >>> The documented existence of such a feature is a risk by itself. >> >> Same logic applied, even the existence of this discussion is a risk by >> itself. It proves that people might use a patched cryptsetup with added >> nuke feature already. > > Yes, it is. That is one of the reasons why I strongly recommend > not taking ecrypted data into danger at all and making sure all > unused space on storage media is zeroed. While in general I agree to your suggestion, Matthias' point rather seems like a non-argument to me. I agree that one should consider possible negative implications of wrong usage of the feature in question. But I don't agree that the risk created by "documented existance of such a feature" is an argument against implementing it. Same logic applied again, we should stop shipping crypto software in distributions at all just because in some countries it might bring you into trouble, right? Kind regards, jonas