From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mps1.wohnheimg.uni-frankfurt.de (mps1.wohnheimg.uni-frankfurt.de [141.2.118.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.server123.net (Postfix) with ESMTPS for ; Wed, 10 Feb 2016 21:07:57 +0100 (CET) Received: from p4fe854e1.dip0.t-ipconnect.de ([79.232.84.225] helo=[192.168.0.11]) (Authed sender Sven 'DarKRaveR' Eschenberg) by mps1.wohnheimg.uni-frankfurt.de via ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim) (envelope-from ) id 1aTb3M-0006la-LH for dm-crypt@saout.de; Wed, 10 Feb 2016 21:07:56 +0100 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> <20160210200256.GQ12867@yeono.kjorling.se> From: Sven Eschenberg Message-ID: <56BB989F.5090805@whgl.uni-frankfurt.de> Date: Wed, 10 Feb 2016 21:07:59 +0100 MIME-Version: 1.0 In-Reply-To: <20160210200256.GQ12867@yeono.kjorling.se> Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit 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 Yes, it will overwrite the header and potential free space after the header up to the first sector of encrypted data. Does this seem so weird? Regards -Sven Am 10.02.2016 um 21:02 schrieb Michael Kjörling: > 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. >