Onion v3 Key Management: Secure Backup and Recovery Guide

A v3 hidden service generates three key files in the hidden service directory: hs_ed25519_secret_key (the private key - 64 bytes, critical), hs_ed25519_public_key (the public key - 32 bytes, derived from private), and hostname (the .onion address - derived from public key). Only hs_ed25519_secret_key needs backup - the other files can be regenerated from it. The secret key file format: 32 bytes of private key material. The .onion address is: base32(sha3-256(public_key)[:10] + version byte + checksum + public_key). Losing hs_ed25519_secret_key = losing the .onion address permanently (cannot recover without the private key).

Primary backup: encrypt hs_ed25519_secret_key with GPG and store the encrypted file in multiple locations. GPG symmetric encryption: gpg --symmetric --cipher-algo AES256 hs_ed25519_secret_key (creates hs_ed25519_secret_key.gpg). The symmetric passphrase must be strong and memorable (or stored separately from the encrypted file). Storage locations: encrypted USB drive (stored in physically secure location), printed paper backup (print hex encoding of the file for paper backup), trusted third party (encrypted file only, not passphrase). Hardware security: consider a hardware security key (Ledger, YubiKey) for additional encryption of the backup file.

Paper backup provides long-term storage resilient to storage media failure (USB drives fail, CDs degrade). Generate a printable version: xxd hs_ed25519_secret_key | fold -w 80 outputs a hex representation. Print this hex dump plus a QR code representation (qrencode can encode the binary file). Store the printed paper in a waterproof sealed envelope, in a fireproof location (safe, safety deposit box). To restore from paper: retype the hex representation and convert back to binary (xxd -r -p hex_input > hs_ed25519_secret_key). Verify the restored file matches the original by comparing SHA256 checksums.

Shamir Secret Sharing splits a secret into N shares where any K shares can reconstruct the secret (K-of-N threshold). Application for hidden service keys: split hs_ed25519_secret_key into 5 shares where any 3 can reconstruct. Distribute 5 shares to 5 trusted people (or locations). If any 2 are lost or compromised, the key remains secure. If any 3 are available, the key can be reconstructed. Tool: ssss (Secret Sharing Scheme) on Linux: ssss-split -t 3 -n 5 -q (then paste the key hex). ssss-combine -t 3 (collect 3 shares). This approach distributes trust - no single person has the complete key.

Recovery from backup: transfer hs_ed25519_secret_key to new server's hidden service directory, ensure correct permissions (chmod 600, chown debian-tor), restart Tor service. Verify recovery: cat /var/lib/tor/hidden_service/hostname should show the original .onion address. If key was compromised (attacker has the private key): generate a new hidden service key (delete the old directory, let Tor regenerate), publish the new .onion address through all channels, run both old and new addresses simultaneously during transition to maintain accessibility, and explicitly communicate the migration to users. There is no way to 'revoke' a compromised .onion key - the attacker can continue operating a hidden service at that address. Migration is the only remedy.