PGP Verification for Market Links and Vendor Messages

A PGP signature on a signed announcement proves one narrow thing: the person who published that message had access to the private key that matches the public key you already hold for that market. It does not prove the market is honest, currently online, or that your order will arrive. It only proves continuity of the keyholder between the moment you received that public key and the moment the new link or maintenance update was signed.

Three things the signature actually demonstrates

Key continuity. If the old onion signed a message containing a new onion, and the signature verifies against a public key you saved weeks ago, then the operator did not appear out of nowhere. A clone page operator does not have that private key, so their signed announcement will fail verification even if their page looks pixel-perfect.

Message integrity. The signed text has not been modified since it left the operator. Someone sitting between you and the announcement cannot swap in a different onion address, a different payment address, or a different maintenance schedule without breaking the signature. The math binds the text to the key.

Timing of intent. A signature created at the time of rotation shows the same keyholder deliberately endorsed the new address. It does not show the operator is safe. It shows they had the same identity credential they had before, which is the only stable anchor when every other surface changes.

1. Keyholder writes update The operator composes plain text stating the new onion and any maintenance window
2. Signature is created The text is signed with the market's long-term PGP key
3. Message is broadcast The signed text and signature travel together through mirrors or paste channels
4. You verify Your saved public key checks the signature against the exact received text
5. Rotated link acceptedIf verification passes, the new onion inherits the trust you already placed in that key

Think of the PGP key as a stamp that cannot be forged in practice: anyone can print a page that looks official, but only one party can press the stamp into the paper. A valid signature is the pressed stamp. It tells you the same hand that marked the old page also marked the new one — not that the hand is benevolent, sober, or solvent.

A signed announcement and a cloned text wall often look identical at first glance: same market name, same wording style, same list of new mirrors. What changes are the parts a signature actually covers — the key that verifies the message and the operator-controlled data inside it. When the operator signs a rotation notice, the signature binds the new address to the same key that signed earlier announcements. A clone can copy the formatting and even reuse the old text, but it cannot produce a fresh signature from the operator’s private key. That is the first concrete difference: the signed update produces a valid, current proof, while the clone either has no signature or carries one that does not match the key already marked as trusted in the reader’s keyring.@@H3 The two visible shifts: key continuity and binding quality@@GLOSSARY Key continuity :: whether the signing key for the new announcement is the same one the operator used on the previous verified update || Binding quality :: whether the signature actually covers the new mirror address and words, or merely sits next to them as decoration || Trusted keyring :: the local set of already verified operator keys a reader has accepted before the rotation happened@@COMPARE What changes between a real update and a clone | Signed operator update | Phishing clone ;; Signature check :: passes against the previously trusted operator key :: fails or points to a new unverified key ;; Mirror address inside the message :: bound to the signature; changing one line breaks the proof :: can be altered freely because no working signature covers it ;; Urgency language :: usually neutral and factual even when asking users to move :: often leans on panic, expiry, or “final warning” to push a fast click ;; Effect on the reader’s keyring :: confirms continuity of the same operator :: attempts to replace trust with a fresh, unearned key @@P That second shift is why an unsigned or badly keyed update reads as an early warning signal, not a minor formatting issue. When an operator has controlled signing habits, serious rotation notices are signed by default — it is part of the message, not an optional extra. A clone operator typically controls the text of a mirrored page but not the signature chain. So the red flag appears before the user clicks anything: the old key says nothing here, or the verification fails immediately.@@P Think of it like a bank branch moving to a new address. The real bank sends the notice on letterhead that matches the previous letterhead and carries the same seal you already checked. A fake notice may use the same logo and the same wording, but the seal is missing, smudged, or made with a different stamp. The text has not changed — the authority behind it has. That gap between copied words and unproven authority is exactly what PGP verification separates.@@COMPARE What the reader compares before trusting the link | Old verification state | New update ;; Signing key :: operator key already marked trusted :: same trusted key signs the new notice ;; Message content :: previous rotation words and mirror list :: new mirror list bound by the signature ;; Clone failure mode :: not applicable before takeover attempt :: clone arrives unsigned or signed by an unknown key ;; Practical red flag :: familiar key signature absent :: reader sees a broken proof before clicking the new onion @@P The practical consequence is that a clone page often tries to make verification feel unnecessary. It tells the reader that “this is the new signed post” while presenting no signature, or that “the key changed for security” while giving no explanation an operator would normally provide. A signed update, by comparison, treats the key as the reason to trust the link — not as an inconvenience to scroll past.

Vendor messages split into two structurally different cases. When a note is encrypted for your public key, only the holder of the corresponding private key can read it. That means the vendor addressed a specific buyer identity, not a broadcast message. It also means any later quote of that message carries less weight unless the reader can independently open the same ciphertext with the same key. The direction of encryption matters more than the message content: it tells you who the counterparty expected to reach and what key material they trusted at that moment.

A vendor who has used one key across orders, disputes, and address changes creates a thread of continuity. If that same key signs a message saying “use this new key”, the transition is anchored to something you already verified. If instead the vendor simply starts signing with a new key after a dispute or a failed delivery, nothing links the new key to the previous identity. An attacker who controls the account could do exactly that.

The distinction becomes sharp in disputes. A buyer who can show that an encrypted order note opens with their private key has something the vendor produced for that specific recipient. If the vendor later claims a different account or key, the evidence does not move across the gap. The value is in the continuity, not in the encryption itself.

Most verification breakdowns are not caused by broken software or a missed character. They come from treating a signed announcement as a permission slip that stays valid, rather than as a single-use receipt tied to one specific moment. A reasonable analogy is a keycard at a hotel: the card proves the front desk issued it for a particular room and date. It does not prove that the person holding it tomorrow still works there, or that the room behind the door has not been renumbered. The signature shows who issued the message and that its content has not changed. It says nothing about what that operator decides to publish next week, and it does not upgrade the link into a safe bookmark.

The analogy starts to break down once mirror rotation enters the picture. A hotel keycard is physically reissued each stay; a signed market link can be copied, forwarded, and reused long after the operator has rotated infrastructure. Reusing the same signed link for months is like checking into a hotel, leaving, and trying to use the same card a year later because the plastic still looks official. The signature was valid for what it was at the time. It is not a contract that the same onion address will remain the only entrance forever.

Another common trap is treating all keys as interchangeable during a mirror switch. A user receives a new link announcement, sees a signature, and assumes the key belongs to the market just because the message looks like a market update. If the same PGP key that signed the previous update did not sign the new one, that is the whole signal. A changed key is not an inconvenience to ignore; it is the difference between a new key and a new operator.

A more confusing version happens with vendor-specific messages. If a vendor sends an encrypted note that mentions market downtime or a mirror change, the user may mentally merge that vendor key with the market key. The vendor signed a message about their own orders or their own availability. A market mirror signed by the market operator is a different identity entirely. Losing track of which key is supposed to sign which kind of announcement turns a routine vendor update into a false sense that the market itself confirmed a link.

A valid signature narrows the risk from “is this the real operator?” to “what has changed since the key was last trusted?” That second question matters more for daily use. Markets can rotate a signing subkey, retire an expired announcement key, or change their preferred contact fingerprint while still being controlled by the same team. Treat a good signature as proof of continuity for that message only — not as a blanket guarantee for every mirror, vendor, or support account connected to the market.

One good signature confirms one message. It does not vouch for the next link, the next alias, or the next person quoting it.

When the signature checks out, the practical next move depends on what the message actually asks you to do. A signed announcement about a new mirror is different from a signed vendor message about your order.

1. Signature checks on a new market link Open the signed announcement and note which fingerprint produced it. If it matches a key you already hold from a previous verified session, compare the new address against the format the market used before. If both line up, the link can be used for browsing.
2. Signature checks but the fingerprint is new or subkey-onlyDo not immediately place an order. The message may still be legitimate — an expiry rotation or a subkey change — but you cannot distinguish that from a takeover without another channel. Wait for a second signed confirmation from a different path, such as a vendor you already trust or a separately saved contact.
3. Signature fails or the message is unsigned Stop and treat every instruction inside as junk. Links, wallet updates, “mandatory password reset” prompts — none of it should be acted on. A clone can copy the wording of a real update while failing the signature.
4. Vendor message decrypts and says your order needs confirmation The encryption proves only that the message was built for your public key. It does not prove the sender is the vendor. Compare the vendor’s signing key history. If the vendor does not sign their messages, ask them to bind the order details to their known PGP identity before you send anything.

A common false confidence comes from treating “signature valid” as “everything safe now.” A signed message can still deliver a link that points to a seized or cloned frontend if the key itself has been quietly replaced earlier. That is why continuity matters more than a single match.