I am confused about several things in the new key agreement code. net/bluetooth/smp.c in two places generates random bytes for the private_key argument to net/bluetooth/ecdh_helper.c:generate_ecdh_keys, which suggests the private key is static within the function. However, there is a do ... while(true) loop within generate_ecdh_keys, with the following near the end: /* Private key is not valid. Regenerate */ if (err == -EINVAL) continue; which suggests that it expects a different private key to be generated on each iteration of the loop. But it looks like it runs through the loop yet again with the same private key generated in the caller, which suggests it would infinitely loop on a bad private key value. Is this incorrect? Furthermore, since req->src == NULL via the call to kpp_request_set_input, ecc_make_pub_key will always be called in ecdh.c:ecdh_compute_value, in which case -EINVAL would be returned only by invalid input (!private_key or bad curve_id) that AFAICT cannot happen, or at least wouldn't be resolved by another run through the loop. OTOH, -EAGAIN would be returned by ecc_make_pub_key if the public key turns out to be the zero point, which is at least one reason why you'd want to generate a new private key (if that loop were to do that.) I'm a little confused about some other things: * The bluetooth code doesn't seem to use ecc_gen_privkey, opting to instead just generate random bytes and hope for the best. * There doesn't appear to be any way for ecc_gen_privkey to get called from crypto/ecdh.c:ecdh_set_secret, as it starts with a call to crypto/ecdh_helper.c:crypto_ecdh_decode_key that returns -EINVAL if decoding fails, meaning that both params.key != NULL and (if I'm reading this correctly) params.key_size > 0. Is that dead code, or is there a way it is intended to be used? The context for this email is that I have need for the same basic functionality in net/bluetooth/ecdh_helper.c for a non-BT purpose, so it seems like this should be part of crypto/ecdh_helper.c (abstracted to work for any curve). Basically, I need to do basic ECDH key agreement: * Generate a new (valid) ephemeral private key, or potentially re-use an existing one * Compute the corresponding public key for the curve * Compute the shared secret based on my private and peer's public Is KPP intended to be an abstract interface to all of the above, e.g., for both ECDH and FFDH? Right now it seems like layer violations are required as there doesn't appear to be any way to (for example) generate a fresh private key via kpp_*. Thanks, Kyle