|
Hi Milan, Thank you very much for the detailed reply. This is again very helpful to us! It's not a problem at all. I appreciate it very very much for you using your family time helping us! I am sorry that I cannot resist asking more questions as your answer indicate more opportunities 8-) If they are very simple to you to answer, thank you for just drop a few lines; if not, you can simply ignore.
1.
You said “…if you have no extra user JSON data stored there”. Can we use that area to store additional user data? How?
2.
To check if a LUKS is in good condition, can we just use isLuks command? Does this cmd trigger some internal sanitary checking?
Thank you, Hualing -----Original Message----- 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://nam02.safelinks.protection.outlook.com/?url=""> 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 |
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
