From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gmazyland@gmail.com>
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com
 [IPv6:2a00:1450:400c:c09::22b])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Wed, 23 Dec 2015 11:50:33 +0100 (CET)
Received: by mail-wm0-x22b.google.com with SMTP id p187so143489828wmp.0
 for <dm-crypt@saout.de>; Wed, 23 Dec 2015 02:50:33 -0800 (PST)
References: <CAFnMBaQHdK-nnUy=LKpQjUb0dZbdpFkn06CTfo=icNdgiHn+Bg@mail.gmail.com>
 <567953A8.9020903@gmail.com>
 <CAFnMBaRyd=NYNBndGK50+MULNUvg-uUWMx14wzCJ9wAGPPotvQ@mail.gmail.com>
 <CAFnMBaRCMb8mpLizYBKinu6+8nnDqJ+_4_6b60tQUVJXsZKHNQ@mail.gmail.com>
 <20151223043004.GD27503@tansi.org>
 <CAFnMBaSTjK5rxcntKH2Q1SreiyHZVox8ruLOb7kyK4UDzEAuTg@mail.gmail.com>
 <20151223062318.GA28898@tansi.org>
 <CAFnMBaRRAUaNqBGbQgP48_BaSRk57ofq4Uqtef7fWDmTszW+_Q@mail.gmail.com>
From: Milan Broz <gmazyland@gmail.com>
Message-ID: <567A7C76.5060508@gmail.com>
Date: Wed, 23 Dec 2015 11:50:30 +0100
MIME-Version: 1.0
In-Reply-To: <CAFnMBaRRAUaNqBGbQgP48_BaSRk57ofq4Uqtef7fWDmTszW+_Q@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] Variable data offset for a LUKS volume that uses a
 detached header.
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: ".. ink .." <mhogomchungu@gmail.com>, "dm-crypt@saout.de" <dm-crypt@saout.de>

On 12/23/2015 09:39 AM, .. ink .. wrote:
>> Hmm. What about actually shifting the partition contents physically?
>>
> The current problem is not on the data offset,but it is on IV offset.
> 
> LUKS API allows setting of data offset and i got it to accept 256
> sector offset by removing the
> current restriction that forces the offset to be either zero or larger
> that header
> size.

Yes but LUKS header does not have attribute for storing IV offset.
New format will allow it, so we can think about using the new header
as "a generic key storage".
(In fact if there is enough space on device we can convert the device metadata
in-place. But that's future...)
 
> Currently,LUKS API does not have an option to set IV offset and my problem would
> be solved if the API is introduced.

I really do not want to workaround problems in other software by introducing
hacks in current version of LUKS.

If you really want this, you can use existing API (open LUKS device/header,
get volume key, open device again in PLAIN mode and use the parameters).
Should be few lines of code.

Milan