Feature Overview
Enable CNSA 2.0–aligned password hashing by supporting PBKDF2 with SHA‑512 (or SHA‑384+) in mu_crypto to replace SHA‑256–based configurations.
Solution Overview
Extend PBKDF2 implementation to support SHA‑512 (preferred) alongside SHA‑384, with configurable iteration counts to meet target latency (e.g., ~100–500 ms). This allows UEFI password hashing to meet CNSA v2 policy requirements while maintaining performance flexibility across platforms.
Alternatives Considered
PBKDF2‑SHA256 (status quo): Not sufficient for CNSA 2.0 compliance.
Argon2id: Stronger but not FIPS/CNSA compliant due to non‑approved hash (BLAKE2).
PBKDF2‑SHA384: Acceptable but SHA‑512 recommended (same cost, stronger baseline).
Urgency
High
Are you going to implement the feature request?
Someone else needs to implement the feature
Do you need maintainer feedback?
No maintainer feedback needed
Anything else?
No response
Feature Overview
Enable CNSA 2.0–aligned password hashing by supporting PBKDF2 with SHA‑512 (or SHA‑384+) in mu_crypto to replace SHA‑256–based configurations.
Solution Overview
Extend PBKDF2 implementation to support SHA‑512 (preferred) alongside SHA‑384, with configurable iteration counts to meet target latency (e.g., ~100–500 ms). This allows UEFI password hashing to meet CNSA v2 policy requirements while maintaining performance flexibility across platforms.
Alternatives Considered
PBKDF2‑SHA256 (status quo): Not sufficient for CNSA 2.0 compliance.
Argon2id: Stronger but not FIPS/CNSA compliant due to non‑approved hash (BLAKE2).
PBKDF2‑SHA384: Acceptable but SHA‑512 recommended (same cost, stronger baseline).
Urgency
High
Are you going to implement the feature request?
Someone else needs to implement the feature
Do you need maintainer feedback?
No maintainer feedback needed
Anything else?
No response