PAKE SIZE macros need more arguments

[athoelke]

This issue has been replicated from a posting to the psa-crypto@lists.trustedfirmware.org mailing list, originally submitted by Oberon.

The PAKE input and output size macros are defined with the argument list (alg, primitive, step). However, some input/output values depend on the digest size of the selected hash algorithm. This holds for instance for a SPAKE2+ confirmation key or the SRP client/server proofs.

It is therefore mandatory to include either the hash algorithm or the hash size in the argument list of the two macros.

[athoelke]

Other options might be to include the hash in the pake primitive, instead of the cipher-suite, but would result in a shortage of available bits in the current 32-bit primitive definition.

It is not possible to use the cipher-suite object itself as a parameter to these macros, as this would defect the design goal of enabling the evaluation to be a compile-time constant.

[athoelke]

This issue is related to the discussion of adding SPAKE2+ support to the PAKE API in #73

[athoelke]

Considering the two options: both would break compatibility for the API, but in different places in the source code. But the introduction of support for SPAKE2+ may do that anyway.

Extra hash parameter

Adding a hash_alg parameter to the macros is simple. This approach requires that the application knows the hash algorithm whenever it uses PSA_PAKE_OUTPUT_SIZE() and PSA_PAKE_INPUT_SIZE(). In some cases this will be a fixed value, known to the application developer, otherwise it can be extracted from the psa_pake_cipher_suite_t that is used for the PAKE operation. In the latter case, the macro will not evaluate to a compile-time constant value.

Move hash from PAKE cipher-suite to PAKE primitive

Adding the hash algorithm to the psa_pake_primitive_t, and removing it from the psa_pake_cipher_suite_t, results in more localised changes in application code - just where the PAKE primitive and cipher-suite are set up. However, we would have to shave some bits off the fields within psa_pake_primitive_t in order to fit a hash algorithm type - which might eventually become an issue if we need enough different of primitive types, families or larger bit sizes.

At the moment psa_pake_primitive_t has 8-bit type, 8-bit family, and 16-bit size. We need room for a nominal 8-bit hash.

In practice we currently only have two types (EC and DH), the ECC families use 6 bits of the 7 available in the key encoding, and the existing hash types use 6 bits out of 8. So we could crop these fields in the PAKE primitive and, for example, use 4 for type (and retain the top bit for vendor-specific), 6 for family, and 6 for hash?