crypto, refactor: add new KeyPair class #30051

Add benchmarks for signing with null and non-null merkle_root arguments. Null and non-null merkle_root arguments will apply the taptweaks H_TapTweak(P) and H_TapTweak(P | merkle_root), respectively, to the private key during signing. This benchmark is added to verify there are no significant performance changes after moving the taptweak signing logic in a later commit. Co-authored-by: l0rinc <pap.lorinc@gmail.com>

Sanity check that using CKey/CPubKey directly vs using secp256k1_keypair objects returns the same results for BIP341 key tweaking. Co-authored-by: l0rinc <pap.lorinc@gmail.com>

Add a `KeyPair` class which wraps the `secp256k1_keypair`. This keeps the secret data in secure memory and enables passing the `KeyPair` object directly to libsecp256k1 functions expecting a `secp256k1_keypair`. Motivation: when passing `CKeys` for taproot outputs to libsecp256k1 functions, the first step is to create a `secp256k1_keypair` data type and use that instead. This is so the libsecp256k1 function can determine if the key needs to be negated, e.g., when signing. This is a bit clunky in that it creates an extra step when using a `CKey` for a taproot output and also involves copying the secret data into a temporary object, which the caller must then take care to cleanse. In addition, the logic for applying the merkle_root tweak currently only exists in the `SignSchnorr` function. In a later commit, we will add the merkle_root tweaking logic to this function, which will make the merkle_root logic reusable outside of signing by using the `KeyPair` class directly. Co-authored-by: Cory Fields <cory-nospam-@coryfields.com>

Use `KeyPair` instead of creating a `secp256k1_keypair` object. The main change here is creating a `KeyPair` instead of a `secp256k1_keypair` and then passing it to the libsec256k1 functions using `reinterpret_cast<secp256k1_keypair*>(keypair)`. The variable name `keypair` is used for the reinterpret_cast to simplify the diff in a later commit when all of the logic in SignSchnorr is moved into the KeyPair class. Note: we no longer need to call memory_cleanse since `KeyPair` is now using a secure allocator (same as CKey). See src/support/allocator/secure.h

Move `SignSchnorr` to `KeyPair`. This makes `CKey::SignSchnorr` now compute a `KeyPair` object and then call `KeyPair::SignSchorr`. The signing logic is move-only with the exception of changing `keypair.data()` to `my_keypair->data()`, since we now have access to the private member `m_keypair`.

Reuse existing BIP340 tests, as there should be no behavior change between the two

Replace early returns in KeyPair::KeyPair() with asserts. The if statements imply there is an error we are handling, but keypair_xonly_pub and xonly_pubkey_serialize can only fail if the keypair object is malformed, i.e., it was created with a bad secret key. Since we check that the keypair was created successfully before attempting to extract the public key, using asserts more accurately documents what we expect here and removes untested branches from the code.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

crypto, refactor: add new KeyPair class #30051

crypto, refactor: add new KeyPair class #30051

Commits on Aug 3, 2024

crypto, refactor: add new KeyPair class #30051

Are you sure you want to change the base?

crypto, refactor: add new KeyPair class #30051

Commits on Aug 3, 2024