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

[Guilhem Moulin]

Hi and thanks Milan for releasing the fix!

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

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.

We might, however, have Buster users with dm-integrity devices using
HMAC integrity protection with keys of size ≥114 bytes.  As such device
actually uses a 114-bytes truncation of the key material, it'll become
unusable once the system upgrades to Bullseye.

2:2.3.6-1 fixes the truncation, but that doesn't solve the fact that the
user won't be able to open the device out of the box: one needs to use
`--integrity-key-size 114` as it's actually using a 114-bytes
truncation (for 2:2.3.5-1 using that option doesn't fix the issue).

So I think we should postpone 2:2.3.6-1 to Bookworm.  But I can't think 
of a smooth upgrade path.  The less disruptive thing that came to mind
was to upload an intermediate “fix” for 2:2.3.5-1 where *114 bytes* keys
are still usable, and spew a warning when the key exceeds that size so
user can update their scripts with `--integrity-key-size 114` for a
smooth upgrade before Bookworm.  But the exact truncation value needs to
be computed with care, HMAC(SHA1) should be able to accomodate 2 more
bytes for instance.  Frankly I'm not even sure it's worth doing, because
standalone dm-integrity devices with HMAC protection is a niche thing,
especially with keys longer than the internal block size.  Maybe we
should just wait until Bullseye is released, and upload the
aforementioned via s-p-u in case we have more reports ;-)  (The current
Bullseye issue is “better” than the Buster one because `integritysetup
open` errors out instead of silently truncate the key, so people using
such devices should notice early enough).

Feedback welcome :-)
-- 
Guilhem.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20210529/7f26cfcf/attachment.sig>