Skip to content

keymgmt: fix HKDF salt parameter validation per PKCS#11 spec#481

Merged
Jakuje merged 1 commit into
latchset:mainfrom
FrantisekKrenzelok:cko_data
Jul 16, 2026
Merged

keymgmt: fix HKDF salt parameter validation per PKCS#11 spec#481
Jakuje merged 1 commit into
latchset:mainfrom
FrantisekKrenzelok:cko_data

Conversation

@FrantisekKrenzelok

Copy link
Copy Markdown
Contributor

The previous version blocked the usage of CKF_HKDF_KEY which is not blocked by pkcs#11 standard and was causing issues.

Replace the null-salt check in CKM_HKDF_DERIVE with proper per-type validation of CK_HKDF_PARAMS.ulSaltType as defined in PKCS#11 v3.0 §2.30.2:

  • CKF_HKDF_SALT_DATA: require non-null pSalt with ulSaltLen > 0
  • CKF_HKDF_SALT_KEY: require a valid hSaltKey handle
  • All other salt types (including CKF_HKDF_SALT_NULL): reject with CKR_MECHANISM_PARAM_INVALID

Description

Checklist

  • Test suite updated
  • Rustdoc string were added or updated
  • CHANGELOG and/or other documentation added or updated
  • This is not a code change

Reviewer's checklist:

  • Any issues marked for closing are fully addressed
  • There is a test suite reasonably covering new functionality or modifications
  • This feature/change has adequate documentation added
  • A changelog entry is added if the change is significant
  • Code conform to coding style that today cannot yet be enforced via the check style test
  • Commits have short titles and sensible text
  • Doc string are properly updated

@Jakuje Jakuje left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i am not much fan of this syntax, but if cargo fmt does not complain, I will not complain either.

@FrantisekKrenzelok

Copy link
Copy Markdown
Contributor Author
match params.ulSaltType {
    CKF_HKDF_SALT_NULL => {
        return Err(CKR_MECHANISM_PARAM_INVALID)?;
    }
    CKF_HKDF_SALT_DATA => {
        if params.pSalt.is_null() {
            return Err(CKR_MECHANISM_PARAM_INVALID)?;
        }
    }
    CKF_HKDF_SALT_KEY => {
        if params.hSaltKey == CK_INVALID_HANDLE {
            return Err(CKR_MECHANISM_PARAM_INVALID)?;
        }
    }
    _ => {
        return Err(CKR_MECHANISM_PARAM_INVALID)?;
    }
}

@Jakuje This was the original I disliked redundancy of the result, but It is more readable. Should i replace it back?

@Jakuje

Jakuje commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

the first match is clearly redundant, the second needs the pSaltLen check, but otherwise I would find this more readable:

match params.ulSaltType {
    CKF_HKDF_SALT_DATA => {
        if params.pSalt.is_null() || params.ulSaltLen == 0 {
            return Err(CKR_MECHANISM_PARAM_INVALID)?;
        }
    }
    CKF_HKDF_SALT_KEY => {
        if params.hSaltKey == CK_INVALID_HANDLE {
            return Err(CKR_MECHANISM_PARAM_INVALID)?;
        }
    }
    _ => {
        return Err(CKR_MECHANISM_PARAM_INVALID)?;
    }
}

@FrantisekKrenzelok

Copy link
Copy Markdown
Contributor Author

yeah the NULL check is pretty redundant... I will use your proposal Thanks!

The previous version blocked the usage of CKF_HKDF_KEY which is not
blocked by pkcs#11 standard and was causing issues.

Replace the null-salt check in CKM_HKDF_DERIVE with
proper per-type validation of CK_HKDF_PARAMS.ulSaltType as defined in
PKCS#11 v3.0 §2.30.2:

- CKF_HKDF_SALT_DATA: require non-null pSalt with ulSaltLen > 0
- CKF_HKDF_SALT_KEY: require a valid hSaltKey handle
- All other salt types (including CKF_HKDF_SALT_NULL): reject with
  CKR_MECHANISM_PARAM_INVALID
@Jakuje
Jakuje merged commit 407e929 into latchset:main Jul 16, 2026
68 checks passed
@FrantisekKrenzelok
FrantisekKrenzelok deleted the cko_data branch July 16, 2026 11:04
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.

2 participants