[PATCH 3/6] dpp_pkex: EC point mul w/ value < prime

[Jouni Malinen]

On Sun, Nov 20, 2022 at 11:15:29AM -0500, Glenn Strauss wrote:
> On Sun, Nov 20, 2022 at 05:53:20PM +0200, Jouni Malinen wrote:
> > On Tue, Nov 08, 2022 at 12:05:51AM -0500, Glenn Strauss wrote:
> > > crypto_ec_point_mul() with mbedtls requires point
> > > be multiplied by a multiplicand with value < prime
> > 
> > crypto_ec_point_mul() could be implemented to handle this internally for
> > crypto libraries that have such constraints on their input values.
> 
> It might be costly for SAE and DPP to have crypto_ec_point_mul()
> check range for every single SAE and DPP call to crypto_ec_point_mul().

All the SAE cases seem to have the scalar reduced so that it is 1 <
scalar < order (or so.. plus/minus 1 differences might exist).

Many, but not all, DPP cases use crypto_ec_point_mul() either with
something that is a private key from a generated key pair or mod prime
reduced value. The PKEX derivation for Qi and Qr is a clear exception
from this as they are using a raw hash value as the scalar when doing
point multiplication.

> > I'm
> > not confident that this specific crypto_ec_point_mul() would be the only
> > one that could reach this type of a case. For example, what about the
> > similar construction in dpp_pkex_derive_Qi()?
> 
> I am not sure either.
> 
> I did not run into it in the hwsim test suite.

Maybe the set of PKEX identifier/code values and MAC addresses there end
up not generating hash values that would result in similar issues.
However, the construction is practically identical and if Qr derivation
has this issue, so does Qi derivation.

> > Is that mbedtls constraint documented somewhere? A quick look at the
> > mbedtls_ecp_mul() documentation did not seem to say anything about the
> > allowed range for the integer (m).
> 
> mbedtls_ecp_mul() calls mbedtls_ecp_check_privkey() and
> mbedtls_ecp_check_pubkey() on its input to validate the arguments.

That function does not sound like a correct implementation of
crypto_ec_point_mul() if it assumes the scalar is a private key..

> mbedtls_ecp_mul() and other parts of mbedtls ecp operate on valid data
> which is on the elliptic curve, and does not make guarantees about
> operations on invalid data.

It is invalid only under the incorrect assumptions about the nature of
the scalar used here. That said, if there is no other function available
for doing scalar multiplication without such constraint, it might make
sense to do what this patch is proposing, but to both
dpp_pkex_derive_Qi() and dpp_pkex_derive_Qr() with a clear source code
comment describing why that step is needed.

-- 
Jouni Malinen                                            PGP id EFC895FA