Re: [dm-crypt] 10 M Luks2 header size?

From: Milan Broz <gmazyland@gmail.com>
To: Hualing Yu <hualing.yu@jci.com>, "dm-crypt@saout.de" <dm-crypt@saout.de>
Subject: Re: [dm-crypt] 10 M Luks2 header size?
Date: Mon, 28 Oct 2019 11:36:38 +0100	[thread overview]
Message-ID: <a415dc42-dbc9-9b7e-6501-b4b5ed4da606@gmail.com> (raw)
In-Reply-To: <CH2P132MB01877105D585DC5F093FE30787670@CH2P132MB0187.NAMP132.PROD.OUTLOOK.COM>

Hi,

sorry for the late reply, I have a lot of personal issues these days,
so this mail was just stuck in the queue - thanks for the reminder.

On 27/10/2019 14:15, Hualing Yu wrote:> Could you please answer my last two questions below?
> 
> 1. I'm using linux kernel keyring as token for passphrase
> (likely one passphrase per LUKS partition).  Do I need to enlarge
> JSON?  (BTW, Why JSON area is stored twice, for backup only that
> area?)

Token (JSON) configuration takes some extra space, but if you
are limited to a few keyslots and few keyring tokens, default
JSON area size should be enough.

You can, of course, increase it during format, but I do not suggest
to use big JSON areas (>1MB).
IOW increasing to 64k should be more than enough if you have no extra user
JSON data stored there.)

The best is if you create the most complicated configuration for your
setup (used all slots + all tokens) and try to configure it.
If cryptsetup doesn't complain that there is not enough space, it is enough :)

For the storing JSON twice - long description is in LUKS2 doc
https://gitlab.com/cryptsetup/LUKS2-docs

It is not backup! We store it twice because LUKS2 expects more frequent
modification of metadata, so we can recover in the case one area is
corrupted (power fail or so).

Also, it increases reliability in the case one area is corrupted
by some other tool (it automatically updates from the second copy).

Note that BINARY area (binary stored keyslot content) is stored
only once (duplication would undermine anti-forensic filter).

> 
> 2.      If we have full filesystem redundancy, do we still need to
> use /luksHeaderBackup/<device> and /luksHeaderRestore/<device> are
> for entire 16 M header backup?  Any suggestion on what to check to
> ensure that the standby (inactivate) luks partition is in good
> condition?

RAID is not a backup. The same applies to redundant LUKS headers.

It increases availability (you can quickly recover if possible), but
you should have offline/offsite backup,

The luksHeaderBackup is in principle just copy of the area with
whole LUKS header (so it contains even unused reserved space,
this space is filled with random data - if it is not conversion
of old header).

I hope this helps.

Thanks,
Milan