From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nekare.kjorling.se (nekare.kjorling.se [89.221.249.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Wed, 10 Feb 2016 21:03:06 +0100 (CET) Received: from yeono.kjorling.se (h-9-65.a328.priv.bahnhof.se [46.59.9.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "yeono", Issuer "yeono" (not verified)) by nekare.kjorling.se (Postfix) with ESMTPS id 781E7114096 for ; Wed, 10 Feb 2016 20:02:58 +0000 (UTC) Received: from yeono.kjorling.se (localhost [127.0.0.1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by yeono (Postfix) with ESMTPS id 05F6C1A15 for ; Wed, 10 Feb 2016 21:02:58 +0100 (CET) Date: Wed, 10 Feb 2016 20:02:56 +0000 From: Michael =?utf-8?B?S2rDtnJsaW5n?= Message-ID: <20160210200256.GQ12867@yeono.kjorling.se> References: <20160208160227.6a446085@lustre.ryper.org> <20160209011150.GB10406@tansi.org> <20160209152824.774e5d25@lustre.ryper.org> <20160209232819.GA21086@tansi.org> <20160210131315.1991cca7@lustre.ryper.org> <20160210192121.GA31043@tansi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160210192121.GA31043@tansi.org> Subject: Re: [dm-crypt] Size of LUKS header and how to overwrite List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On 10 Feb 2016 20:21 +0100, from arno@wagner.name (Arno Wagner): > On Wed, Feb 10, 2016 at 20:13:15 CET, Subscriptions wrote: >> dd if=/dev/urandom of=/dev/sda1 bs=512 count=8 > > That will have killed the header, not the key-slots. As the > header contains an unguessable salt, this is already pretty > secure. > > To also kill the keyslots, run something like > > dd if=/dev/urandom of=/dev/sda1 bs=512 count=4096 > > if you have "Payload offset: 4096". Or run Out of curiosity; are you saying that for a given, known, _specific_ LUKS container, the first "payload offset" × 512 bytes is what we need to overwrite if we want to securely erase the entire LUKS header on that container without collateral damage? (Leaving the encrypted data untouched.) Let's ignore here the issue of "overwriting" _anything at all_ on SSDs and SSHDs. -- Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se “People who think they know everything really annoy those of us who know we don’t.” (Bjarne Stroustrup)