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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
