Skip to content

Correct LUKS hash handling#544

Open
sarroutbi wants to merge 2 commits intolatchset:masterfrom
sarroutbi:202602191433-update-correct-hash-treatment
Open

Correct LUKS hash handling#544
sarroutbi wants to merge 2 commits intolatchset:masterfrom
sarroutbi:202602191433-update-correct-hash-treatment

Conversation

@sarroutbi
Copy link
Collaborator

@sarroutbi sarroutbi commented Feb 25, 2026

When a LUKS device is formatted with a non-default hash algorithm (e.g. sha512), clevis operations that add or update key slots (bind, regen, edit) did not pass the original hash to cryptsetup, causing new slots to silently default to sha256.

Add clevis_luks_get_hash() to extract the device's hash algorithm from the LUKS header (supports both LUKS1 "Hash spec:" and LUKS2 "Hash:" fields). Use it in clevis_luks_add_key() and clevis_luks_update_key() to pass --hash to cryptsetup, preserving the original hash algorithm.

Add unit tests for bind, regen and edit operations on both LUKS1 and LUKS2 devices formatted with sha512, verifying the hash is preserved through each operation.

@sarroutbi sarroutbi force-pushed the 202602191433-update-correct-hash-treatment branch 3 times, most recently from 71c64df to 4783a1e Compare February 25, 2026 08:04
When a LUKS device is formatted with a non-default hash algorithm
(e.g. sha512), clevis operations that add or update key slots
(bind, regen, edit) did not pass the original hash to cryptsetup,
causing new slots to silently default to sha256.

Add clevis_luks_get_hash() to extract the device's hash algorithm
from the LUKS header (supports both LUKS1 "Hash spec:" and LUKS2
"Hash:" fields). Use it in clevis_luks_add_key() and
clevis_luks_update_key() to pass --hash to cryptsetup, preserving
the original hash algorithm.

Add unit tests for bind, regen and edit operations on both LUKS1
and LUKS2 devices formatted with sha512, verifying the hash is
preserved through each operation.

Co-Authored-By: Claude <[email protected]>
Signed-off-by: Sergio Arroutbi <[email protected]>
@sarroutbi sarroutbi force-pushed the 202602191433-update-correct-hash-treatment branch from 4783a1e to a77ac7f Compare February 25, 2026 08:06
Address code review findings for the hash handling logic:

- Fix LUKS2 hash extraction to target keyslot sections specifically,
  avoiding false matches from digest sections that may use a different
  hash algorithm.
- Add input validation to clevis_luks_get_hash() using POSIX-compatible
  case pattern matching, rejecting values containing characters outside
  [a-zA-Z0-9_-] to prevent command argument injection via crafted LUKS
  headers.
- Replace echo with printf for safe output of hash values.
- Suppress cryptsetup stderr on extraction to handle missing or
  unreadable devices gracefully.
- Add fallocate fallback to dd in new_device_hash() for CI
  environments where fallocate is not supported.

Add unit tests for hash extraction and validation:
- get-hash-luks1: tests extraction across multiple algorithms
  (sha256, sha512, sha384, sha1, ripemd160) and error handling
  for empty, non-existent, and non-LUKS devices.
- get-hash-luks2: same coverage for LUKS2, plus verification that
  keyslot hash is returned rather than digest hash.
- get-hash-validation: exercises the validation logic directly
  against injection patterns (semicolons, command substitution,
  backticks, pipes, spaces, ampersands, empty strings).

Co-Authored-By: Claude <[email protected]>
Signed-off-by: Sergio Arroutbi <[email protected]>
@sarroutbi sarroutbi marked this pull request as ready for review February 27, 2026 10:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant