|
Hi Milan, Thank you very much for the detailed explanation! This is tremendous help to us! I had already brought this up in our group meeting. We will re-arrange out partitions to ensure all have enough space for default configurations. Thank you very much on that! May I ask further – (sorry more questions, I just want to do it right and make the best out from your original design.)
1.
I’m using linux kernel keyring as token for passphrase. Do I need to enlarge JSON? (BTW, Why JSON area is stored twice, for backup only that area?)
2.
Do we still need to use luksHeaderBackup <device> and
luksHeaderRestore <device> are for entire 16 M header backup? This means each luks partition needs 32 M for its header! Now here is our story : We have storage redundancy on our board, that is, for each component (for example linux rootfs) we have two partitions to save two copies of the component. I think with that, we may
not need luks header backup. When we detect anything wrong with current active partition, include luks header, we can switch to use the standby partition for rootfs for example, and then repair, or simply wipe everything and redo luks format and copy the
data into it. Should this work? Can you suggest some ways, or check points, for our background task to periodically checking to ensure all luks’s are good, in case you have something on top of your head? 8-) Thank you so much! Hualing -----Original Message----- Hi, this information should be later in FAQ, so I try to explain it here. Anyway, stay with defaults, if you can. On 19/10/2019 21:59, Hualing Yu wrote: > > May I ask a couple of additional questions about this so that we know how to trade off. > > > 1. What the reencryption can do for us? Could you explain very > briefly as I’m not sure if we need it? In principle it can perform changes that requires full-device rewrite (change of the volume key). See man cryptsetup-reencrypt - just for LUKS2 it is more reliable and mainly online (you can use device while it is in reencryption process). See slides from Ondra
https://nam02.safelinks.protection.outlook.com/?url=""> There should be also some online demos Reencryption demo:
https://nam02.safelinks.protection.outlook.com/?url=""> Encryption demo:
https://nam02.safelinks.protection.outlook.com/?url=""> For this we require some reserved area for storing temporary encryption data. > 2. We need only one or at most two keyslots but we do want them > to be scattered as much as needed just as if for the default case,
> what we can do? Use –luks2-keyslots-size=1 M (or whatever size that
> will give two key enough space to scatter)? There are two areas (see LUKS2 docs) - JSON area for metadata and binary area. JSON has small binary header, than JSON data (it is 16k currently, stored twice). For the binary area, it depends what you need, exact size depends on the stored key size (here the binary keyslot data are stored, exactly the same as in LUKS1). I would expect you are using current default for disk encryption, AES256-XTS. Then you need to store 512bit (2x256bit) key in each binary keyslot. With the LUKS AF filter and 4k alignment it should be 256KiB of binary data per keyslot. So for 1M and 512bit key it allows 4 LUKS keyslots here. > 3. What the size of metadata size for default configuration? > What’s the downside of using 16 K? The whole LUKS2 default header takes 16MiB. For JSON area it is 16k, stored twice (we will increase it later, this is for compatibility reasons), for binary area - it is "16M - 2x16k" (16M minus JSON areas). There is only several possible sizes of JSON area you can use (see LUKS2 docs), binary area is basically arbitrary with maximum 128M, it must be aligned to 4k sectors. JSON areas allows to store user token metadata, so if you do not need it, no need to enlarge it. Thanks, Milan |
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
