From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sven@whgl.uni-frankfurt.de>
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 <dm-crypt@saout.de>; Wed, 10 Feb 2016 21:29:05 +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 <sven@whgl.uni-frankfurt.de>) id 1aTbNo-0006mY-Hh
 for dm-crypt@saout.de; Wed, 10 Feb 2016 21:29:04 +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>
 <56BB989F.5090805@whgl.uni-frankfurt.de>
 <20160210201350.GR12867@yeono.kjorling.se>
From: Sven Eschenberg <sven@whgl.uni-frankfurt.de>
Message-ID: <56BB9D93.7020804@whgl.uni-frankfurt.de>
Date: Wed, 10 Feb 2016 21:29:07 +0100
MIME-Version: 1.0
In-Reply-To: <20160210201350.GR12867@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: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: dm-crypt@saout.de

Ah, I see. Well the FAQ gives alternatives and more information on the 
size of the header for different keylengths and so on. But as the 
header+keymaterial can hardly be bigger than the offset of the encrypted 
payload on the backing device a dd with count=payload-offset and bs=512 
indeed does the trick.

Of course you'd have to check the payload offset of that particular 
container and not mix any numbers etc. .

Regards

-Sven


Am 10.02.2016 um 21:13 schrieb Michael Kjörling:
> On 10 Feb 2016 21:07 +0100, from sven@whgl.uni-frankfurt.de (Sven Eschenberg):
>> 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?
>
> No, but given the somewhat roundabout way this was described in the
> FAQ at least last I looked, this seems like a much easier way to
> describe it...
>