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 wWIxASeg5Dyq for ; Sun, 15 Dec 2013 03:55:36 +0100 (CET) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.saout.de (Postfix) with ESMTPS for ; Sun, 15 Dec 2013 03:55:36 +0100 (CET) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vs1rh-0002NI-Vw for dm-crypt@saout.de; Sun, 15 Dec 2013 03:55:33 +0100 Received: from c-98-227-220-190.hsd1.il.comcast.net ([98.227.220.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Dec 2013 03:55:33 +0100 Received: from rnicholsNOSPAM by c-98-227-220-190.hsd1.il.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Dec 2013 03:55:33 +0100 From: Robert Nichols Date: Sat, 14 Dec 2013 20:55:22 -0600 Message-ID: References: <52A8B602.4030303@riseup.net> <20131211191607.GA9082@fancy-poultry.org> <20131211205516.GA21128@citd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <20131211205516.GA21128@citd.de> 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 12/11/2013 02:55 PM, Matthias Schniedermeyer wrote: > 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. The whole point of the anti-forensic splitter in LUKS is to require that all stripes (4000 by default) of the key material be recovered exactly in order to get the master key. Even if you can recover 99.9% of that material, you are no better off than brute-forcing the master key. For a non-hybrid HDD, even the most cursory overwrite is going to destroy _some_ of that key material. NAND Flash is indeed much trickier. It doesn't (much**) matter what data you overwrite with since the only thing that actually wipes the old data is the block erase by the Flash controller. The problem is that even though the block with the old data has been marked as not in use, there is no guarantee as to when the controller will get around to doing the block erase. (And, TRIM is irrelevant here -- the block was written to. Ergo, the old one is no longer in use. TRIM is used to inform the device of blocks that are available even though they have _not_ been rewritten.) **The only time that would matter would be if you _knew_ that your write was going to be directed to a free block that had previously been used for key material. At a minimum, you would have to write at least enough data to fill the (unknown) number of currently unallocated blocks to have any assurance of that happening. -- Bob Nichols "NOSPAM" is really part of my email address. Do NOT delete it.