[pkg-cryptsetup-devel] Bug#949336: integritysetup: HMAC(SHA256) key truncated to 106/114bytes in standalone mode

[Jonas Meurer]

Hey Guilhem :)

Guilhem Moulin wrote:
> I'm not sure how what the best way to proceed for Bullseye.  Jonas,
> what's your take about this?

First sorry for not responding earlier. I simply missed this mail in my 
backlog :-/

> I tried to summarize the regression at
> https://gitlab.com/cryptsetup/cryptsetup/-/issues/648#note_575895772 .
> (Note that the truncation doesn't affect LUKS or dm-crypt, but *only*
> standalone dm-integrity devices using HMAC integrity protection with
> long key files, which is not widespread.)  It manifests in different
> ways depending on cryptsetup and kernel versions:
> 
>    * Stretch has cryptsetup <2.0.0 which doesn't have integritysetup(1)
>      and is therefore unaffected.
>    * For cryptsetup ≥2.0.0 and ≤2.0.4 (some time between the Stretch and
>      Buster releases), devices are formatted and opened using a
>      *106-bytes* truncation of the key material.  Moreover formatting
>      errors out when default sector size 512 bytes is used (so one needs
>      to format with --sector-size [1024|2048|4096]).
>    * For cryptsetup ≥2.0.5 (Buster and Bullseye), devices are formatted
>      and opened using a *114-bytes* truncation of the key material.
> 
> So dm-integrity devices that were formatted using cryptsetup ≥2.0.0 and
> ≤2.0.4 using HMAC integrity protection with >106-bytes long keys don't
> open normally (one needs to use `--integrity-key-size 106`) in Buster
> and later.  We uploaded 2:2.0.5-1 to sid on October 29 2018; an entire
> recycle cycle has since gone by and so far only n.f.b. has reported the
> issue.  Given the many “if”s and the lack of bug reports I think it's
> fair to assume than not maybe used long HMAC keys with integritysetup
> between v2.0.0 and v2.0.4.
> 
> In addition: when using cryptsetup ≥2.3 on Linux 5.5 or later, it's not
> possible to open a dm-integrity device using HMAC integrity protection
> with keys of size exceeding *113 bytes*, regardless of whether it was
> formatted using the same integritysetup binary or an older version.
> cryptsetup 2:2.3.0-1 and linux 5.5.13-1 were respectively uploaded to
> sid on March 04 and March 30 2020; Bullseye is affected and one year
> later no one has reported the issue.

I would suggest to take the most pragmatic approach and don't care about 
this corner case. Given that, no stable release ever shipped with a 
faulty integritysetup and that I would expect every user who ran 
unstable/testing back when keys hat 106 bytes to still run 
unstable/testing, let's just keep it the way it is, no?

> So I think we should postpone 2:2.3.6-1 to Bookworm.

Agreed.

> Maybe we
> should just wait until Bullseye is released, and upload the
> aforementioned via s-p-u in case we have more reports ;-) 

Sounds like a good plan.

Thanks for taking care, Guilhem :)

Cheers
  jonas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20210607/f7c92175/attachment.sig>