Hidden Service Key Ceremony and Backup Procedures for Production Operations

Generate the hidden service key on the server where it will be used, not on a laptop or development machine. Generating on the production server eliminates the risk of the key being copied during a transfer operation. When Tor generates the key, it uses the operating system's cryptographically secure random number generator (/dev/urandom on Linux), which is appropriate for production key generation.

If the operational requirement is to generate the key on an air-gapped machine and then transfer it to the server (for organizations with strict key generation policies), use a machine that has never been connected to the internet, generate the key using mkp224o or by running Tor in isolation, and transfer via USB with full disk encryption after verifying the air-gapped machine has no network capabilities.

After initial key generation, read the onion address from /var/lib/tor/hidden_service/hostname and verify it matches your expected format (56 characters, ending in .onion). Store this address separately from the key itself. The address can be shared publicly; the private key files must never be shared or transmitted in plaintext.

Shamir's Secret Sharing (SSS) allows splitting a secret into N shares such that any K of them can reconstruct the original secret, but fewer than K shares reveal nothing. For hidden service key backup, a 3-of-5 scheme means the key is split into 5 shares distributed to 5 trusted custodians, and any 3 of them together can reconstruct the key if needed. Two custodians colluding cannot reconstruct the key, nor can a single custodian loss permanently destroy it.

The ssss tool (apt install ssss) implements Shamir's scheme: echo "BASE64_ENCODED_KEY" | ssss-split -t 3 -n 5 -q generates 5 shares. Distribute each share to a separate custodian via an encrypted channel. Custodians should store their share on an encrypted device stored in a physically secure location.

Document the reconstruction procedure for custodians. They need to know: what their share is for, how to contact the other custodians, how to use ssss-combine to reconstruct from 3 shares, and what to do with the reconstructed key after a recovery event. This documentation should be encrypted and stored with each share.

The most critical backup mistake is assuming a backup is complete without verifying recovery. After creating the initial key backup, perform a full recovery test on a separate VPS before the production service goes live. This test verifies that the backup files are complete, the restoration procedure is understood and documented, and the reconstructed key generates the correct onion address.

Recovery test procedure: provision a test VPS, copy the key files from backup to the HiddenServiceDir location, set correct ownership and permissions, start tor, and verify that /var/lib/tor/hidden_service/hostname contains the expected onion address. If it matches, the backup is verified. If it does not match, there is a backup problem that must be resolved before the production service goes live.

Run this verification test annually in addition to the initial test. Key backup media can degrade, custodians can lose their shares, and documentation can become outdated. Annual testing catches these problems before they become acute during an actual recovery need.

Production hidden service keys do not need to be rotated on a fixed schedule (unlike passwords or TLS certificates). The onion v3 key remains cryptographically secure indefinitely unless the ed25519 cryptographic scheme is broken, which is not anticipated in any published cryptographic research. Rotate keys only when there is a specific reason: suspected compromise, custody change, or organizational policy requirement.

Planned key rotation requires advance notice to users because the onion address changes permanently. Announce the new address through all channels where the old address was published. Maintain the old hidden service running (alongside the new one) for a transition period of at minimum 30 days, preferably 90 days for established services, to allow all users to update bookmarks and contacts.

Document key custody changes. When a custodian leaves an organization or a custody arrangement changes, run a new SSS ceremony with new shares and new custodians. Destroy old shares through verified secure deletion. Maintain a chain of custody log for the key that records who held custody, when changes occurred, and what verification was performed at each handoff.