Re: Authenticated Encryption with external Data Integrity Fields

Hello,

Thanks for the response.

> On Apr 2, 2024, at 6:52 AM, Milan Broz wrote:
> Hi,
>> On 4/2/24 4:15 AM, Alex Lieflander wrote:
>> Hello,
>> I’m trying to add authenticated encryption to my setup, but I’m
>> having trouble to configure some of the parameters. I know that
>> `cryptsetup` with --integrity only supports some of the options that
>> `integritysetup` does, so I’m wondering if I could instead create the
>> integrity layer myself and tell `cryptsetup` to pass down its
>> integrity tags (like it does with the --integrity option).
> 
> No, you cannot do that. Authenticated encryption through dm-crypt
> (with dm-integrity proividend only additional per-sector space) can
> be configured only with LUKS2 and cryptsetup.
> 
> But the AEAD algorithm configuration for LUKS2 will need some update.
> What is missing for your config?

Just for context, I have a 24TB RAID5 backed by 6x4TB CMR HDDs, and 2 individual SSDs. It’s all consumer-grade hardware, so the performance is just adequate. In my testing, `integritysetup` yields very poor performance unless I specify a separate --data-device and use --integrity-bitmap-mode. I’ve tried tweaking all other parameters, but so far I haven’t found any other combination with sufficient performance.

So currently my biggest concern is just improving performance, and the best/only way to do that seems to be with a separate --data-device (or to a lesser extent a very large --interleave-sectors). I also think being able to add/use integrity protection while “preserving length” (on the protected device) would be really useful.

>> If that isn’t currently possible, are there any plans to add that
>> feature in the future?
> 
> No, this is not planned. But see below.
> 
>> It could also be used to take advantage of physical hardware with T10/DIF support.
> 
> Existing hw formats usually only supports 512 + 8 bytes sector, this is not enough for AEAD.
> 
> But NVMe drives can be configured to actually support other per-sector additional space.
> IMO this feature is currently available only to "enterprise" storage I do not have access to.
> 
> But once such configuration is reliable and available on some generic NVMe drives, I definitely
> want to add support for it (IOW replace dm-integrity by this hw-only solution - this was actually
> long-term plan; dm-integrity was originally only proof-of-concept.)
> 
>> Alternatively, are there any
>> future plans to support using a separate device for the integrity
>> tags like `integritysetup` can with --data-device?
> 
> No. We already support detached LUKS2 header, with separate device for integrity
> tags this means maintaining 3 separate devices, this would create too complex scenario.

Fair enough. I’m happy to wing it when it comes to integrity because the stakes are pretty low, but I know better than to try implementing any encryption myself. I figure that if I leave the dm-crypt portion alone, then the dm-integrity portion can be hacky and precarious.

> The long-term plan should head to hw backed support mentioned above, that would also
> increase performance as it removes the need for dm-integrity journal.
> 
> Milan


Alex