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 1YlWH3wSFXuz for ; Wed, 11 Dec 2013 21:55:25 +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 ; Wed, 11 Dec 2013 21:55:25 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by awesome.dsw2k3.info (Postfix) with ESMTP id B0507C48F7 for ; Wed, 11 Dec 2013 21:50:27 +0100 (CET) Received: from awesome.dsw2k3.info ([127.0.0.1]) by localhost (awesome.dsw2k3.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veEZJO0yFs9g for ; Wed, 11 Dec 2013 21:50:22 +0100 (CET) Received: from citd.de (p579BD72C.dip0.t-ipconnect.de [87.155.215.44]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by awesome.dsw2k3.info (Postfix) with ESMTPSA for ; Wed, 11 Dec 2013 21:50:22 +0100 (CET) Date: Wed, 11 Dec 2013 21:55:16 +0100 From: Matthias Schniedermeyer Message-ID: <20131211205516.GA21128@citd.de> References: <52A8B602.4030303@riseup.net> <20131211191607.GA9082@fancy-poultry.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131211191607.GA9082@fancy-poultry.org> Subject: Re: [dm-crypt] Possibility for safe Luks partition delete functionality List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 11.12.2013 20:16, Heinz Diehl wrote: > On 11.12.2013, tada wrote: > > > I was wondering if it is possible to add something like shred or wipe > > functionality for Luks devices, call it luksWipe, to safely delete the > > luks header > > You can do that easily by running dd against the first MB's of the > respective partition.. > > dd if=/dev/zero of=/dev/sdaX That heavily depends on who is the "bad guy" and what storage technology is used. For a non-hybrid HDD a single pass is suppossed to be enough to permanently overwrite anything there was before, no recourse whatsoever. (Or only the millions of dollar range, a.k.a. "State sponsored enemys") Non-rotating-platters-of-rust, namely NAND-Flash, are much trickier. If you only need to defend against an attacker investing a handfull of dollars (a.k.a, let's connect the thing and see what we get with standard "get me block X"-commands) a single overwrite/TRIM/Secure Erase is enough. But with just slightly more money (a.k.a., let's desolder the chips and see what's the raw contents) it's gets tricky pretty fast. Like you have to overwrite the (whole(?!)) contents with random data several times and you would still not have a 100% guranteed that the original content is really overwritten and not sitting somewhere as "spare" waiting to be reused. Altough at least some current SSD (don't know which ones) are supposed to be secure if you use Secure Erase. Thoses SSDs always encrypt the content as a way to guaranteed randomness of the data, which is supposed to be better for the flash-cells. So when you need a "scrambler" anyway, you just use AES256 and also have something you can advertise, 2 flies 1 stone. So when you secure erase such a SSD it (supposedly) discards the previous encryption key and generates a new one. If that is implemented correctly (which you or i can't really proven one way or the other) it would be safe. A single Secure Erase (overwriting not necessary) effectivly would make the problem "you need to brute force an AES256 key" to even get to the RAW content. -- Matthias