Fixup HKDF-Expand-Label algorithm#1051
Merged
igaw merged 5 commits intolinux-nvme:masterfrom Aug 22, 2025
Merged
Conversation
hreinecke
force-pushed
the
hkdf-fixes
branch
4 times, most recently
from
2de5ac3 to
d3a4104
Compare
If nvme_generate_tls_key_identity() fails we should set errno to return a more detailed error to the caller. Signed-off-by: Hannes Reinecke <[email protected]>
Add a testcase for TLS identity derivation to catch errors from the HKDF-Expand-Label algorithm changes. Signed-off-by: Hannes Reinecke <[email protected]>
The function __nvme_insert_tls_key() is only called from __nvme_import_keys_from_config(), so rename it to __nvme_import_tls_key() to avoid a name clash with __nvme_insert_tls_key_versioned(). Signed-off-by: Hannes Reinecke <[email protected]>
…key() Rename to shorten the function name for better readability. Signed-off-by: Hannes Reinecke <[email protected]>
There are issues with the Retained and TLS PSK derivations due to the
implementation not adhering to the RFC 8446 definition of the
HKDF-Expand-Label function.
1) The 16-bit HkdfLabel.length value must be converted to network byte
order.
2) The variable length HkdfLabel.label and HkdfLabel.context vectors
must be prefixed with a length byte.
To not break existing implementations keep the original algorithms with
as compat versions and update the 'psk' testcase to cover both versions.
Signed-off-by: Chris Leech <[email protected]>
Signed-off-by: Hannes Reinecke <[email protected]>
Collaborator
|
Alright, not much else we can do here. Looks good. Thanks! |
Collaborator
|
strange one build on mainline failed in the psk tests: https://github.com/linux-nvme/libnvme/actions/runs/17155560911/job/48671470694 I can also reproduce it locally with |
Collaborator
|
Collaborator
|
This might be related with the openssl version which is pulled in via the fallback mechanism. |
Collaborator
|
The fallback uses OpenSSL-3.0.8 which is not the latest in the LTS branch but still supported in upstream. So we either update the dependency on OpenSSL correctly or make the code backwards compatible with OpenSSL 3.0.x LTS version. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi all,
here's my attempt to fixup the HKDF-Expand-Label algorithm. The first patch (from Chris Leech) implements the RFC-conformant algorithm for HKDF-Expand-Label, and the second patch adds back the original implementation via a new function nvme_import_tls_key_compat()