All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hualing Yu <hualing.yu@jci.com>
To: Milan Broz <gmazyland@gmail.com>,
	"dm-crypt@saout.de" <dm-crypt@saout.de>
Subject: Re: [dm-crypt] 10 M Luks2 header size?
Date: Mon, 21 Oct 2019 16:13:08 +0000	[thread overview]
Message-ID: <CH2P132MB0187F6574C7736A42B09AFFA87690@CH2P132MB0187.NAMP132.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <4eea62ab-e121-d069-9be2-048b09cf301e@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5126 bytes --]

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-----
From: Milan Broz [mailto:gmazyland@gmail.com]
Sent: Sunday, October 20, 2019 6:08 AM
To: Hualing Yu <hualing.yu@jci.com>; dm-crypt@saout.de
Subject: Re: [dm-crypt] 10 M Luks2 header size?



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=https%3A%2F%2Fokozina.fedorapeople.org%2Fonline-disk-reencryption-with-luks2-compact.pdf&amp;data=02%7C01%7Chualing.yu%40jci.com%7Ca096abcf38e8483e599808d7554555fc%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C1%7C637071628596824108&amp;sdata=Zn13uT%2B7wsLKex3r6u3LWAC7xFobCn4PLs10ywQYxeU%3D&amp;reserved=0



There should be also some online demos

  Reencryption demo: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fasciinema.org%2Fa%2F268573&amp;data=02%7C01%7Chualing.yu%40jci.com%7Ca096abcf38e8483e599808d7554555fc%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C1%7C637071628596824108&amp;sdata=6DkH8Bwz699zeGzk25vf8gh4%2FKuImVaMeGEu34qHkCA%3D&amp;reserved=0

  Encryption demo: https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fasciinema.org%2Fa%2F268574&amp;data=02%7C01%7Chualing.yu%40jci.com%7Ca096abcf38e8483e599808d7554555fc%7Ca1f1e2147ded45b681a19e8ae3459641%7C0%7C1%7C637071628596824108&amp;sdata=8nuvhvj5fBB%2FeH0pu0%2F0qRNd7l47dVMQwzDrNFoeeMA%3D&amp;reserved=0



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

[-- Attachment #2: Type: text/html, Size: 13930 bytes --]

  reply	other threads:[~2019-10-21 16:13 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-18 19:24 [dm-crypt] 10 M Luks2 header size? Hualing Yu
2019-10-19  7:07 ` Milan Broz
2019-10-19 18:47   ` Hualing Yu
2019-10-19 19:59     ` Hualing Yu
2019-10-20 10:07       ` Milan Broz
2019-10-21 16:13         ` Hualing Yu [this message]
2019-10-27 13:15           ` Hualing Yu
2019-10-27 18:33             ` Arno Wagner
2019-10-28 10:36             ` Milan Broz
2019-10-28 13:50               ` Hualing Yu
2019-10-29 13:07                 ` Milan Broz
2019-10-29 15:03                   ` Hualing Yu
2019-11-03  3:33                     ` Hualing Yu
2019-11-04 10:33                       ` Ondrej Kozina
2019-11-04 14:59                         ` Hualing Yu
  -- strict thread matches above, loose matches on Subject: below --
2019-10-18 19:04 Hualing Yu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CH2P132MB0187F6574C7736A42B09AFFA87690@CH2P132MB0187.NAMP132.PROD.OUTLOOK.COM \
    --to=hualing.yu@jci.com \
    --cc=dm-crypt@saout.de \
    --cc=gmazyland@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.