Key agreement interface may present the shared key material out of the secured space.

[tranvantruonggit]

psa_raw_key_agreement and psa_key_derivation_key_agreement use the pointer to key to store the result of the key exchange. In the application where the Diffie-Hellman key exchange are used, the result of the DH (regardless it is raw or derived) can be used for another cryptographic service like the block cipher or MAC. In my opinion, it is more consistent to use the psa_key_id_t * key as a parameter to drain the result of the DH operation.

Edit: typos and grammar

[athoelke]

This is probably a good idea, and one that we missed during the changes to the way keys are managed for the 1.0.0 version of the API.

A simple approach would be to add a new API, perhaps:

psa_status_t psa_key_agreement(psa_algorithm_t alg,
                               psa_key_id_t private_key,
                               const uint8_t * peer_key,
                               size_t peer_key_length,
                               const psa_key_attributes_t * attributes,
                               psa_key_id_t* shared_secret);

On success, *shared_secret is a derivation key containing the shared secret from the agreement. Here are some issues for discussion relating to this API:

• We cannot do without attributes entirely, as we need to set the usage policy (flags and permitted algorithm) for the shared secret key.
• Is the output key always of type PSA_KEY_TYPE_DERIVE? - if so, can we permit (or require?) the caller to leave the key type as the default PSA_KEY_TYPE_NONE in *attributes?
• Typically the size of the output key is specific to the key agreement algorithms and input key type. Should we require that the caller leave the key size (key_bits) unset in *attributes?
• Does it make any sense for the result of a key exchange to be a persistent key? - given that for many key agreement algorithms it is necessary to use a key derivation function to produce an unbiased secret for use as a cryptographic key.
• Should the output key always be in the same location as the private_key?
• Should there be any requirements or limitations on the usage flags that the caller can request for the shared secret? - PSA_KEY_USAGE_DERIVE is the obvious one

[tranvantruonggit]

@athoelke my idea about the new API is slightly deffirent

psa_status_t psa_raw_key_agreement(psa_algorithm_t alg,
                                   psa_key_id_t private_key,
                                   const uint8_t * peer_key,
                                   psa_key_id_t shared_key);

The shared key shall not be allowed to have PSA_KEY_USAGE_EXPORT. the shared_key shall be prepared by the caller.

Then for your question:``

• I think the output key shall always the PSA_KEY_TYPE_DERIVE to avoid using biased key.
• The size of the output shall be the attribute of the share_key which is prepared before.
• I don't think the result shall always be persistent. Indeed, I think we should prevent the shared_key to be persistent.
• Generally, the private key shall not be replaced by the shared secret. Because there is the scheme that 2 parties use static key pairs, thus the private key shall be kept.

[tranvantruonggit]

I think it is good to refer to NIST SP 800 56A in this case.

Which this discussion, I am wondering where the output of the psa_key_derivation_key_agreement is stored? As mentioned above, it shouldn't replace the private key.

[athoelke]

The shared key shall not be allowed to have PSA_KEY_USAGE_EXPORT. the shared_key shall be prepared by the caller.

In the Crypto API, keys are always immutable once created (this is an intentional design feature) - it is not possible to allocate the shared key object, and then pass it into a function which sets the key data. In all of the APIs that can create keys (psa_generate_key(), psa_import_key(), psa_copy_key(), psa_key_deriviation_output_key()), the caller provides some key attributes and the function creates and returns a key id.

In some of those APIs, the caller has a lot of freedom to set up the key attributes, but in psa_copy_key() (for example) most of the attributes must either match the key being copied, or be unset.

[tranvantruonggit]

If so, I am with you about the return the keyId via pointer and the input key attribute.Tran Van TruongOn 7 Aug 2023, at 16:16, Andrew Thoelke ***@***.***> wrote: The shared key shall not be allowed to have PSA_KEY_USAGE_EXPORT. the shared_key shall be prepared by the caller. In the Crypto API, keys are always immutable once created (this is an intentional design feature) - it is not possible to allocate the shared key object, and then pass it into a function which sets the key data. In all of the APIs that can create keys (psa_generate_key(), psa_import_key(), psa_copy_key(), psa_key_deriviation_output_key()), the caller provides some key attributes and the function creates and returns a key id. In some of those APIs, the caller has a lot of freedom to set up the key attributes, but in psa_copy_key() (for example) most of the attributes must either match the key being copied, or be unset. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[athoelke]

Also thinking about this API could have a parallel in the PAKE API: see these comments to #73.

It seems that some protocols (such as SPAKE2+ draft02), take the raw key exchange output and split this into two pieces for key confirmation, and application use as the shared secret. This suggests that the output key functionality should support being called more than once (perhaps depending on algorithm) in order to construct multiple keys from sequential parts of the key agreement output. This is similar to the support in the key derivation API for calling psa_key_derivaton_output_key() more than once.

This would imply that the key attributes can (or must?) specify a size, to indicate how much of the output is used to construct the key. If more data is requested than is available, then the PSA_ERROR_INSUFFICIENT_DATA error (from the key derivation API) can be reused here. Since key agreement algorithms have a fixed amount of output, we could still permit an unset key size to indicate that the entire output is used to construct the key? - this would reduce the client code for the simple scenarios, but add some complexity for the implementation.

[athoelke]

Which this discussion, I am wondering where the output of the psa_key_derivation_key_agreement is stored? As mentioned above, it shouldn't replace the private key.

If this question is related to the existing psa_key_derivation_key_agreement() API, then the shared secret is transferred to the key derivation operation. The operation must have been set up with a combined key agreement and key derivation algorithm: this function performs the key agreement part of that, and feeds the result in as the indicated step of the key derivation algorithm.

[athoelke]

This would imply that the key attributes can (or must?) specify a size, to indicate how much of the output is used to construct the key. If more data is requested than is available, then the PSA_ERROR_INSUFFICIENT_DATA error (from the key derivation API) can be reused here. Since key agreement algorithms have a fixed amount of output, we could still permit an unset key size to indicate that the entire output is used to construct the key? - this would reduce the client code for the simple scenarios, but add some complexity for the implementation.

🤦 And I've just remembered that the key agreement API is a single-part function, so using it to construct multiple key objects by splitting the output is not an option here (though it is for PAKE).

As such, I suggest to not solve the 'split key agreement output' problem for now, other than via psa_raw_key_agreement(), and just focus on the 'create derivation key from key agreement' use case.

[tranvantruonggit]

I think I agree with you about the prioritization of the fixing the raw key agreement, as we already have the psa_key_derivation_key_agreement is doing exactly what we expect from the key protection view point. I think just some limitation note on the API is more than enough.