Skip to content

[guardian] dev tool: recover a restarted guardian's BTC key from S3 shares#692

Draft
0xsiddharthks wants to merge 1 commit into
mainfrom
siddharth/guardian-dev-recover
Draft

[guardian] dev tool: recover a restarted guardian's BTC key from S3 shares#692
0xsiddharthks wants to merge 1 commit into
mainfrom
siddharth/guardian-dev-recover

Conversation

@0xsiddharthks

Copy link
Copy Markdown
Contributor

Adds hashi-guardian-init tools dev-recover, the recovery counterpart to dev-bootstrap. Under the ceremony model the master secret is generated inside the enclave and Shamir-split to the KP PGP keys, with encrypted shares persisted to S3 (#685) and the SecretSharingInstance in the ceremony log (#687). A restart loses the in-memory BTC key and nothing currently rebuilds it from S3 — this does.

  • recovery mode: reads the ceremony's SecretSharingInstance + encrypted KP shares from S3, decrypts t of them with a local gpg homedir (cross-checking each against the ceremony commitments), then drives OperatorInit -> GetGuardianInfo -> ProvisionerInit reusing the ceremony's instance and a recovered limiter state (so a restart doesn't reset the rate-limit bucket). Asserts the post-init enclave BTC pubkey matches the on-chain guardian_btc_public_key.
  • --print-master-pubkey: decrypts t shares and combines them locally to print the x-only master pubkey; no chain/RPC/guardian contact. Used at genesis to capture the pubkey to pin on-chain, since a ceremony-mode guardian never exposes it directly.

Reuses the ceremony gpg-decrypt helper, the S3 GuardianReader, and limiter_recovery; promotes three dev_bootstrap helpers to pub(crate).

Dev-scoped and clearly marked as such: the production recovery path runs each KP's share through the relay (the provisioner flow Luke/Deepak own), not one gpg homedir. Not for the prod path.

Decrypted-share plaintext is the 32-byte big-endian secp256k1 scalar (Share::value.to_bytes()), share id taken from the KPEncryptedShare — same format ceremony verify decrypts.

cargo check/clippy -D warnings clean; cargo nextest run -p hashi-guardian-init green (32 tests, incl. 3 new pure share-decrypt/commitment/reconstruct tests that don't need gpg or S3).

…hares

Adds `hashi-guardian-init tools dev-recover`, the recovery analogue of
dev-bootstrap. Instead of generating a fresh master secret, it reconstructs
the guardian's existing one from the ceremony key-shares persisted to S3.

- recovery mode: reads the ceremony SecretSharingInstance + encrypted KP
  shares from S3, decrypts t of them with a local gpg homedir, then drives
  OperatorInit -> GetGuardianInfo -> ProvisionerInit reusing the ceremony's
  instance and a recovered limiter state (so a restart doesn't reset the
  rate-limit bucket). Asserts the post-init enclave BTC pubkey matches the
  on-chain guardian_btc_public_key.
- --print-master-pubkey: decrypts t shares and combines them locally to
  print the x-only master pubkey; no chain/RPC. Used at genesis to capture
  the pubkey to pin on-chain (a ceremony-mode guardian never exposes it).

Reuses the ceremony gpg-decrypt helper, the S3 GuardianReader, and
limiter_recovery; makes three dev-bootstrap helpers pub(crate). Dev-scoped:
the production recovery path runs each KP's share through the relay, not one
gpg homedir.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant