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 pgH7BE5mAROP for ; Fri, 17 Jan 2014 16:16:41 +0100 (CET) Received: from awesome.dsw2k3.info (unknown [IPv6:2a01:198:661:1f::3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Fri, 17 Jan 2014 16:16:41 +0100 (CET) Date: Fri, 17 Jan 2014 16:16:36 +0100 From: Matthias Schniedermeyer Message-ID: <20140117151636.GA18116@citd.de> 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> <52D93DE2.3060805@freesources.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52D93DE2.3060805@freesources.org> 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 Cc: dm-crypt@saout.de On 17.01.2014 15:27, Jonas Meurer wrote: > 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. There is a difference, it is relativly easy to prove you don't have anything encrypted(*), but it's hard to prove you didn't use a documented part of the encryption software you are using. So, the mere existance of encryption software doesn't increase the risk of people not using encryption software as there is a "provability" of not using encryption. The same "provability" is NOT given in the case of "nuking" or e.g. the "Hidden Volumes"-Feature of Truecrypt. *: Ignoring Steganography -- Matthias