~ This returns the secret and/or public key for this node. */
| 183 | |
| 184 | /*~ This returns the secret and/or public key for this node. */ |
| 185 | static void node_key(struct privkey *node_privkey, struct pubkey *node_id) |
| 186 | { |
| 187 | u32 salt = 0; |
| 188 | struct privkey unused_s; |
| 189 | struct pubkey unused_k; |
| 190 | |
| 191 | /* If caller specifies NULL, they don't want the results. */ |
| 192 | if (node_privkey == NULL) |
| 193 | node_privkey = &unused_s; |
| 194 | if (node_id == NULL) |
| 195 | node_id = &unused_k; |
| 196 | |
| 197 | /*~ So, there is apparently a 1 in 2^127 chance that a random value is |
| 198 | * not a valid private key, so this never actually loops. */ |
| 199 | do { |
| 200 | /*~ ccan/crypto/hkdf_sha256 implements RFC5869 "Hardened Key |
| 201 | * Derivation Functions". That means that if a derived key |
| 202 | * leaks somehow, the other keys are not compromised. */ |
| 203 | hkdf_sha256(node_privkey, sizeof(*node_privkey), |
| 204 | &salt, sizeof(salt), |
| 205 | &secretstuff.hsm_secret, |
| 206 | sizeof(secretstuff.hsm_secret), |
| 207 | "nodeid", 6); |
| 208 | salt++; |
| 209 | } while (!secp256k1_ec_pubkey_create(secp256k1_ctx, &node_id->pubkey, |
| 210 | node_privkey->secret.data)); |
| 211 | |
| 212 | #if DEVELOPER |
| 213 | /* In DEVELOPER mode, we can override with --dev-force-privkey */ |
| 214 | if (dev_force_privkey) { |
| 215 | *node_privkey = *dev_force_privkey; |
| 216 | if (!secp256k1_ec_pubkey_create(secp256k1_ctx, &node_id->pubkey, |
| 217 | node_privkey->secret.data)) |
| 218 | hsmd_status_failed(STATUS_FAIL_INTERNAL_ERROR, |
| 219 | "Failed to derive pubkey for dev_force_privkey"); |
| 220 | } |
| 221 | #endif |
| 222 | } |
| 223 | |
| 224 | /*~ This returns the secret and/or public x-only key for this node. */ |
| 225 | static void node_schnorrkey(secp256k1_keypair *node_keypair, |
no test coverage detected