CKR_KEY_INDIGESTIBLE in C_DigestKey when key CKA_EXTRACTABLE = false about softhsmv2 HOT 7 CLOSED

Please see #29 for more details on why we added this check. There is nothing in the spec that disallow this behavior. The text "for some reason" makes it valid to make a policy decision. But the check could be removed if we find it unusable.

from softhsmv2.

What about white listing the trusted hash schemes like SHA-X? The arguments in #26 do not apply here. When looking into the code I see that in C_DeriveKey CKM_SHA1_KEY_DERIVATION is not supported. So this does not seem to be an option as alternative.
Is there any other way how you are supporting key derivation schemes based on a given key?

Is there a chance in the future to support key derivation schemes using a nonce, e.g. just nonce+key or more elaborate schemes like HKDF?

from softhsmv2.

A good option would be to implement CKM_SHA1_KEY_DERIVATION in SoftHSM. Currently we only support CKM_DH_PKCS_DERIVE, CKM_ECDH1_DERIVE, CKM_DES_ECB_ENCRYPT_DATA, CKM_DES_CBC_ENCRYPT_DATA, CKM_DES3_ECB_ENCRYPT_DATA, CKM_DES3_CBC_ENCRYPT_DATA, CKM_AES_ECB_ENCRYPT_DATA, CKM_AES_CBC_ENCRYPT_DATA.

Or as you say to whitelist algorithms like SHA-X.

What would you prefer? With the derive option there is still a possibility to keep the derived key "on-board".

from softhsmv2.

I'm fine with both options, the white listing is good enough for me right now, because it opens the complete SHA has family and I do not need the key after the derivation.

from softhsmv2.

We will do whitelisting of algorithms for C_DigestKey().

from softhsmv2.

Fixed in #300

from softhsmv2.

Thanks. I have now finally updated the SoftHSMv2 library and not using my patched version anymore.

from softhsmv2.