What are best practices for onion site operators to publish and sign their PGP keys?

Checked on November 28, 2025
Disclaimer: Factually can make mistakes. Please verify important information or breaking news. Learn more.

Executive summary

Onion-site operators commonly publish and sign PGP keys to let visitors verify an actual service endpoint and to prevent impersonation; forum and market guides recommend publishing a PGP public key alongside the onion address and signing the address so users can validate it (examples of this practice appear across darknet market and Tor project discussions) [1][2]. Several marketplace-style sites also emphasize treating PGP verification as mandatory for trust and to avoid phishing or man‑in‑the‑middle attacks [2][3].

1. Publish the public key where users expect it — multiple, independent locations

Operators should publish their PGP public key in more than one place so visitors can cross-check copies: display the key on the onion site itself and on an independently hosted clearnet page or trusted repository such as a project GitHub page, which commentators have explicitly recommended for onion services [1]. Marketplace directories and gateway lists likewise advise cross‑referencing PGP signatures against “official sources” to confirm legitimacy before connecting [3][4].

2. Sign your onion address with the key — let the signature be the proof

Sign the exact onion address with the operator’s private PGP key and publish that signed blob next to the address; the signature lets users verify that the onion address is tied to the published key rather than to a copycat site (this approach is advocated in community discussions about signing .onion addresses and displaying the public key on GitHub or sites) [1]. The OnionShare thread explicitly proposes signing the .onion address and showing the public key across platforms to reduce forgery and MITM risk [1].

3. Require users to verify signatures — make verification part of the workflow

Good practice is not only to publish signatures but also to instruct users how to verify them and to make verification routine. Darknet market guides emphasize that PGP verification is mandatory for communications and gateway validation, and they instruct users to “always verify PGP signatures before establishing connections” to avoid phishing and fraudulent endpoints [2][3].

4. Use independent verifiers and directories to increase confidence

List the signed key and signed address in reputable, independently maintained directories or gateway lists so third parties can corroborate authenticity; several market directories position themselves as verification sources and urge users to cross‑reference PGP signatures against official listings [3][4]. Independent mirrors and directories can reduce single‑point‑of‑failure trust issues inherent to publishing only on the onion site.

5. Operational security for key handling — separate master keys and air gaps

Operational best practices for key management noted in PGP how‑to narratives include keeping master keys offline (air‑gapped) and using subkeys for day‑to‑day signing and encryption—this model preserves a high‑value master key while permitting operational signatures from subkeys (this general key‑management approach is described in practical PGP guides referenced in community collections) [5]. Back up private keys to secure storage and use strong passphrases or hardware protection as described in PGP tutorials [5].

6. Make the verification UX straightforward — scripts and displayed checksums

Community proposals suggest integrating verification helpers into operator documentation or tooling (for example, showing the signed onion address prominently and linking to a public key on GitHub). The OnionShare discussion recommends displaying the PGP public key on both GitHub and the operator’s website to simplify verification for users [1]. Market pages echo this by providing signed links and instructions to “verify onion links with PGP signature” [6].

7. Acknowledge limitations and adversarial context

Publishing signed keys reduces but does not eliminate risk: directories or clearnet mirrors can be malicious or coerced, and users who fail to verify signatures remain exposed. Several marketplace-style sites still stress that PGP verification is necessary precisely because impersonation and phishing are common threats [2][3]. Available sources do not provide a formal, standardized protocol that all onion operators must follow — practices vary by community and site (not found in current reporting).

8. Competing perspectives and hidden incentives

Market directories promoting “verified” onion lists have an incentive to present themselves as authoritative to capture traffic; their recommendations to cross‑reference PGP signatures increase perceived trustworthiness of those directories [3][4]. Conversely, open‑source project threads (e.g., OnionShare) frame signing as a user‑security enhancement without commercial motive, focusing on reducing MITM and forgery [1]. Readers should treat directory claims and “official” gateway listings with scrutiny and perform independent verification via the published PGP signatures [3].

Summary takeaway: publish your PGP public key and a signed onion address in multiple independent locations (onion site, clearnet/GitHub, directories), sign the address with a secured private key (ideally using an offline master and operational subkeys), require and document signature verification for users, and rely on independent third‑party listings only as corroboration — all guidance supported across community discussions and marketplace guidance in the sources [1][2][3][5].

Want to dive deeper?
What are the advantages and risks of using PGP vs. modern alternatives (e.g., OpenPGP replacements or secure messaging) for onion site operators?
How can onion site operators securely generate, store, and backup PGP keys to resist theft and accidental loss?
What are best practices for publishing PGP key fingerprints and verifying them via Tor-accessible channels (site, keybase, mirrors, printed material)?
How should onion site operators design a PGP key rotation and revocation plan, including automating revocation notices on the onion site?
What operational security (OpSec) steps should onion site operators follow when signing keys, publishing signatures, and responding to compromise on the Tor network?