This issue has been replicated from a posting to the psa-crypto@lists.trustedfirmware.org mailing list, originally submitted by Oberon.
The PAKE interface deliberately does not contain functions for setup calculation not directly involved in the PAKE protocol. This might be a good idea to keep things simple and easy to use. However, there must be a way to do calculations like the password hash somehow. Otherwise the whole PAKE interface turns out to be useless in many situations. In most PAKE protocols a password hash or password verifier is not just a hash but needs field or group calculations related to the main PAKE operation. To allow an implementation of all parts of a PAKE key exchange without relying on a second crypto library, it is mandatory to provide these functions somehow in PSA, in special PAKE functions or in another interface.
This is highly protocol dependent. For SPAKE2+ for instance, the password hash consists of the values w0 and w1 on client side and w0 and L on server side. w0 and w1 are derived using PBKDF2 but in addition they must be reduced modulo the DH/EC group order. L is the group scalar product of w1 and the group base element. The reduction and the scalar multiplication are missing in the PSA API.
Lacking these operations, we could use the raw password as input instead of the derived values but this would compromise security, at least on the server side where no raw passwords should be kept.
A common approach is to expect the unreduced PBKDF2 values on client side but provide separate function for w0 and L to get the password hash on server side. This interface is used for instance in the Matter crypto PAL.
This issue is part of the discussion relating to the addition of support for SPAKE2+ in #73.
This issue has been replicated from a posting to the psa-crypto@lists.trustedfirmware.org mailing list, originally submitted by Oberon.
The PAKE interface deliberately does not contain functions for setup calculation not directly involved in the PAKE protocol. This might be a good idea to keep things simple and easy to use. However, there must be a way to do calculations like the password hash somehow. Otherwise the whole PAKE interface turns out to be useless in many situations. In most PAKE protocols a password hash or password verifier is not just a hash but needs field or group calculations related to the main PAKE operation. To allow an implementation of all parts of a PAKE key exchange without relying on a second crypto library, it is mandatory to provide these functions somehow in PSA, in special PAKE functions or in another interface.
This is highly protocol dependent. For SPAKE2+ for instance, the password hash consists of the values w0 and w1 on client side and w0 and L on server side. w0 and w1 are derived using PBKDF2 but in addition they must be reduced modulo the DH/EC group order. L is the group scalar product of w1 and the group base element. The reduction and the scalar multiplication are missing in the PSA API.
Lacking these operations, we could use the raw password as input instead of the derived values but this would compromise security, at least on the server side where no raw passwords should be kept.
A common approach is to expect the unreduced PBKDF2 values on client side but provide separate function for w0 and L to get the password hash on server side. This interface is used for instance in the Matter crypto PAL.
This issue is part of the discussion relating to the addition of support for SPAKE2+ in #73.