You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looks like the latest nvme-cli is overly restrictive in terms of permitted key lengths for the various hash functions used in NVMe in-band auth. For e.g. it currently enforces a strict key length of 32, 48 & 64 for the SHA-256, SHA-384 & SHA-512 hash functions respectively.
As per NIST SP 800-57, there is a lot more room for flexibility in this area. For e.g. a key length of 32 bytes should probably be acceptable for SHA-384 & SHA-512 hash functions as well.
The text was updated successfully, but these errors were encountered:
8.13.5.1` Protocol Operations
For an NVM subsystem, the controller is the entity running the protocol, using the identity and credentials
of the NVM subsystem. The DH-HMAC-CHAP protocol proceeds in the following order:
1. [...] For DH-HMAC-CHAP, the authentication protocol descriptor includes the list of hash functions (HashIDList) and Diffie-
Hellman group identifiers (DHgIDList) that may be used in this authentication protocol transaction
Why should allow anything else except 32, 48 or 64 key length when there is no matching hash function identifier?
Again, there are no identifier in the current nvme spec defined for different key lengths. Any upcoming changes in the spec can't be implemented until the relevant document has been publicly released.
Looks like the latest nvme-cli is overly restrictive in terms of permitted key lengths for the various hash functions used in NVMe in-band auth. For e.g. it currently enforces a strict key length of 32, 48 & 64 for the SHA-256, SHA-384 & SHA-512 hash functions respectively.
As per NIST SP 800-57, there is a lot more room for flexibility in this area. For e.g. a key length of 32 bytes should probably be acceptable for SHA-384 & SHA-512 hash functions as well.
The text was updated successfully, but these errors were encountered: