This issue has been replicated from a posting to the psa-crypto@lists.trustedfirmware.org mailing list, originally submitted by Oberon.
The suggested PAKE interface passes the resulting raw common secret directly to a key derivation operation. This is good to avoid direct usage of the secret but it makes it impossible to derive more than one key from the secret because the key derivation operation can only be used once. Deriving multiple keys is mandatory for some protocols for instance to get a session key for the rest of the pairing phase and in addition a long term key to establish further sessions.
For example, HomeKit derives several temporary keys as well as the long term secret key from the SRP common secret. A single key derivation operation cannot be used because the separate keys are derived with separate salt and info values.
It would be better to return the raw secret as a key which can only be used as input to a key derivation operation. This would be easy to use and allows for multiple derived keys.
The same problem exists for the key agreement interface which is also directly coupled to a key derivation operation. Again there exists protocols where multiple keys are needed, for instance one for outgoing and one for incoming messages. In the case of key agreement, the psa_raw_key_agreement() function can often be used as a workaround but returning a derivation only key instead of the coupling to a key derivation operation would be a more general and cleaner solution. [This related issue has also been raised as #85]
This issue has been replicated from a posting to the psa-crypto@lists.trustedfirmware.org mailing list, originally submitted by Oberon.
The suggested PAKE interface passes the resulting raw common secret directly to a key derivation operation. This is good to avoid direct usage of the secret but it makes it impossible to derive more than one key from the secret because the key derivation operation can only be used once. Deriving multiple keys is mandatory for some protocols for instance to get a session key for the rest of the pairing phase and in addition a long term key to establish further sessions.
For example, HomeKit derives several temporary keys as well as the long term secret key from the SRP common secret. A single key derivation operation cannot be used because the separate keys are derived with separate salt and info values.
It would be better to return the raw secret as a key which can only be used as input to a key derivation operation. This would be easy to use and allows for multiple derived keys.
The same problem exists for the key agreement interface which is also directly coupled to a key derivation operation. Again there exists protocols where multiple keys are needed, for instance one for outgoing and one for incoming messages. In the case of key agreement, the
psa_raw_key_agreement()function can often be used as a workaround but returning a derivation only key instead of the coupling to a key derivation operation would be a more general and cleaner solution. [This related issue has also been raised as #85]