Equivalent of --integrity-recalculate

Equivalent of --integrity-recalculate

[Marc SCHAEFER]

Hello,

If you create a cryptsetup/luks device with integrity with:

   cryptsetup luksFormat -q --type luks2 --integrity hmac-sha256 $dev

and then open it:

   cryptsetup open $dev backup-copy

you then get, according to lsblk, two additional devices:

   - backup-copy (the transparently decrypted/encrypting volume)

   - backup-copy_dif (the integrity device)

(which is similar, AFAIK, as when you use dm-integrity with LVM)

If you create an integrity device separately, you get a

   integritysetup --integrity-recalculate open $dev integrity

command which allows to recalculate the integrity blocks.

I don't think cryptsetup has this option (*); is there a way to
do it anyway?  Or maybe remove the backup-copy_dif and
re-add it?

Thank you for any pointer.

(*) it looks there is a feature request pending
       https://gitlab.com/cryptsetup/cryptsetup/-/issues/854

Re: Equivalent of --integrity-recalculate

[Milan Broz]

On 5/10/25 5:51 PM, Marc SCHAEFER wrote:
> Hello,
> 
> If you create a cryptsetup/luks device with integrity with:
> 
>     cryptsetup luksFormat -q --type luks2 --integrity hmac-sha256 $dev
> 
> and then open it:
> 
>     cryptsetup open $dev backup-copy
> 
> you then get, according to lsblk, two additional devices:
> 
>     - backup-copy (the transparently decrypted/encrypting volume)
> 
>     - backup-copy_dif (the integrity device)
> 
> (which is similar, AFAIK, as when you use dm-integrity with LVM)
> 
> If you create an integrity device separately, you get a
> 
>     integritysetup --integrity-recalculate open $dev integrity
> 
> command which allows to recalculate the integrity blocks.
> 
> I don't think cryptsetup has this option (*); is there a way to
> do it anyway?  Or maybe remove the backup-copy_dif and
> re-add it?

No, because such option is not implemented (and never will be) in dm-crypt.

Note, for integritysetup you use dm-integrity, for cryptsetup
dm-integrity only provides metadata space, AEAD encrypton
is performed in dm-crypt above.

Sometimes it is not even possible, AEAD just cannot take
data with wrong authentication tag and fix it.
This is only possible when the integrity is calculated separately.

Milan

Disabling integrity metadata verification (was: Equivalent of --integrity-recalculate)

[Marc SCHAEFER]

Hello,

Thank you for this insight:

On Sat, May 10, 2025 at 06:18:18PM +0200, Milan Broz wrote:
> Note, for integritysetup you use dm-integrity, for cryptsetup
> dm-integrity only provides metadata space, AEAD encrypton
> is performed in dm-crypt above.

So, if I understand well, integrity with cryptsetup is implemented with a HMAC
that needs cleartext data (just before encryption) and produce hashed-signed
integrity data that protects against tampering and is not fixable by an
attacker (resistant to voluntary corruption).

Where if I create a dm-integrity layer with a luks crypted volume on top, I get
integrity, but an attacker can modify the crypted data and the hash easily
(only resistant to accidental corruption).

Now, another question: assuming the metadata space is corrupted, but I know
that the crypted space is not, is it possible to ignore the metadata altogether
(to not produce read errors)?

Thank you.

Re: Disabling integrity metadata verification

[Milan Broz]

Hi,

On 5/11/25 10:25 AM, Marc SCHAEFER wrote:
...
> So, if I understand well, integrity with cryptsetup is implemented with a HMAC
> that needs cleartext data (just before encryption) and produce hashed-signed
> integrity data that protects against tampering and is not fixable by an
> attacker (resistant to voluntary corruption).

Cryptsetup (dm-crypt) always use AEAD (authenticated encryption).

Simplified, this can be constructed two ways

  - it is "true" AEAD algorithm (like AEGIS) with one key. You cannot separate
authenticated tag calculation here.

- it is constructed as combination of length-preserving cipher (AES-XTS) and
authentication tag (HMAC). It uses two independent keys in this case.
While we use kernel AEAD interface, it can be split and the authentication
tag verification ignored.

So you can ignore authentication tag in the second option, but you cannot "fix"
it without knowledge of the key.

> Where if I create a dm-integrity layer with a luks crypted volume on top, I get
> integrity, but an attacker can modify the crypted data and the hash easily
> (only resistant to accidental corruption).

I am not sure I understand what you mean. there is always dm-integrity, but
in the case of AEAD it provides only storage, dm-crypt performs both encryption
and authentication.

Stacking dm-crypt with length-preserving encryption over standalone dm-integrity
with HMAC over ciphertext (produced by dm-crypt above) does not make much sense,
but authentication tag still cannot be modified by attacker as HMAC is keyed algorithm.

Use of non-keyed algorithms for integrity protection (xxhash, CRC or plain hash) does
not much sense in combination with encryption, but it can be useful for triggering
recovery in RAID in the case of random data corruption.

> Now, another question: assuming the metadata space is corrupted, but I know
> that the crypted space is not, is it possible to ignore the metadata altogether
> (to not produce read errors)?

It depends, see above - it can be done only in the second option.
Cryptsetup does not support it, but in some related issue I already explained the trick.

Milan