psa_key_derivation_input_key on a secret input (PSA_KEY_DERIVATION_INPUT_SECRET or PSA_KEY_DERIVATION_INPUT_PASSWORD) that is passed as a key allows the following operations:
You can't use a verify function on a key with only the DERIVE usage. This is similar to signature keys not automatically allowing verification. However, I'm not sure that's desirable. For backward compatibility, you might have a key created against the 1.0 API (which only had USAGE_DERIVE) and want to use it with the 1.1 API's verify_xxx functions.
Allowing DERIVE keys to be used as a secret for verify_bytes wouldn't change the security of the key, since you can simulate it with output_bytes followed by memcmp. Allowing DERIVE keys to be used as a secret for verify_key changes what you can effectively do with the keys involved, but I can't think of a scenario where this change would be problematic.
Are there good hygiene reasons to forbid verify_bytes and verify_key with a secret input that only allows USAGE_DERIVE?
psa_key_derivation_input_keyon a secret input (PSA_KEY_DERIVATION_INPUT_SECRETorPSA_KEY_DERIVATION_INPUT_PASSWORD) that is passed as a key allows the following operations:output_xxx(psa_key_derivation_output_bytes(),psa_key_derivation_output_key()) only if the secret key has the policyPSA_KEY_USAGE_DERIVE.verify_xxx(psa_key_derivation_verify_bytes(),psa_key_derivation_verify_key()) only if the secret key has the policy PSA_KEY_USAGE_VERIFY_DERIVATION.You can't use a verify function on a key with only the DERIVE usage. This is similar to signature keys not automatically allowing verification. However, I'm not sure that's desirable. For backward compatibility, you might have a key created against the 1.0 API (which only had
USAGE_DERIVE) and want to use it with the 1.1 API'sverify_xxxfunctions.Allowing DERIVE keys to be used as a secret for
verify_byteswouldn't change the security of the key, since you can simulate it withoutput_bytesfollowed bymemcmp. Allowing DERIVE keys to be used as a secret forverify_keychanges what you can effectively do with the keys involved, but I can't think of a scenario where this change would be problematic.Are there good hygiene reasons to forbid
verify_bytesandverify_keywith a secret input that only allowsUSAGE_DERIVE?