PGP Messaging Etiquette on Markets: Encrypting Order Notes and Handling Key Changes

Most buyers lose money on markets, and it’s rarely a hack. It’s a plaintext message. An address typed into the wrong field. A vendor whose key changed mid-escrow and a buyer who didn’t notice. PGP gets treated as a box to tick during checkout. Then it gets handled sloppily for the thirty seconds it actually matters.

This is a walkthrough of the etiquette side: how to write an order note that survives a dispute, what happens when a vendor’s key changes, and why some of the defaults baked into the marketplace scripts are working against you.

What goes into an order note, and what stays out

An order note is not a conversation. It is a persistent record. Depending on the marketplace’s configuration, that note may sit alongside the order through the entire escrow window, into dispute mediation, and beyond. Treat it accordingly.

Good order notes have four things and nothing else:

• The item and quantity, restated so there’s no ambiguity if the listing changed between order and fulfilment.
• The full shipping address in the exact field or line structure the vendor expects.
• Any variant instruction (size, packaging, no signature) in plain terms.
• A signature: your own PGP-signed block so the vendor can confirm the note came from you and wasn’t tampered with in transit.

Signing matters more than most people realise. Per standard PGP practice, a signature proves the message originated from you and was not modified. If you didn’t sign, a vendor has no cryptographic way to distinguish your order note from a platform admin who inserted an address swap. Investigators who can’t decrypt the body can still see the envelope metadata; a missing signature is the easiest thing in the world to exploit. Sign every note that carries an address.

What does not belong in a note: anything you’d rather not have quoted back at you in a dispute thread. Rude remarks. Dead-names of previous vendors. Codes. Some scripts now support optional PGP key import at registration alongside TOTP or hardware second factors, which means account recovery can hinge on your private key. That same feature means anything you attach to the account lives longer than you think.

The address trap nobody warns you about

Encrypt the note, not the envelope. A market’s internal messaging interface may itself be wrapped in PGP at the script level, so marketplace operators can’t read buyer-vendor exchanges even if they wanted to. That doesn’t protect you from malicious behaviour on the vendor side or from a hostile admin who swaps fields at the web layer.

Two rules:

• The address goes inside the PGP block, never in a separate “delivery instructions” field that renders client-side.
• The recipient you encrypt to must match the fingerprint on the vendor’s profile at the moment you encrypt, not the one you memorised last month.

I’ve seen buyers paste the product name in plaintext because the form “required” it. The form doesn’t require it. The vendor just prefers it. Push back. The vendor who genuinely needs a plaintext product label is telling you something about how they store records.

When a vendor’s key changes

This is the part that catches experienced buyers. A vendor updates their PGP key, sometimes because the old one was compromised, sometimes because they rotated it for hygiene, sometimes because someone is impersonating them. You will see a new ASCII-armored public key block on the profile. You must treat it exactly the way you’d treat a password reset from a suspicious channel: verify before trusting.

Here’s the problem. Verification requires a separate channel. PGP adoption materials are clear that comparing a key fingerprint through a trusted out-of-band channel (a phone call, an in-person meeting, a signed message on a historically-trusted key) is what prevents a man-in-the-middle attack. On a darknet market, you have no such channel for most vendors. So you build substitute trust: check that the new key is also signed by the old key, check that the vendor’s dispute history is intact across the transition, check that the new key fingerprint appears on at least two external directories the vendor controls.

If none of that checks out, the right move is not “trust the vendor’s forum post.” The right move is escrow: keep the transaction inside an escrow window (scripts typically use a five-to-fifteen day confirmation period) and file a dispute if anything feels off. The mistake I see most often is buyers who accept the new key and then go direct-deal on the next purchase to “save fees.” That is a two-loss trade. No escrow, no dispute path, and a key rotation that may or may not be legitimate.

One more wrinkle: some scripts now let users upload a PGP key at registration. That key may become your only recovery path. If a vendor rotates their key mid-deal, your PGP-encrypted order history doesn’t automatically follow. Depending on the platform, past messages remain encrypted to the old recipient, which is fine for you (you can still decrypt your own sent copies if you saved them), but the vendor may struggle to prove delivery if they’ve lost the old key. Save your encrypted outbound messages as local text files. The convention (copy the entire -----BEGIN PGP MESSAGE----- to -----END PGP MESSAGE----- block) makes this trivial. Do it every time.

Tooling and the defaults that bite

I use GPG on a Tails box for anything that touches an address. It’s ugly, it works, and every command is copy-pasteable into a text file you can audit later. If you’d rather use a GUI, KeychainPGP is one of the few browser-resident options that runs locally (WebAssembly, nothing sent server-side), which is a meaningful distinction on a machine that might later be examined. The desktop version adds a clipboard auto-clear after 30 seconds. Nice. Not enough. It clears after you’ve decrypted. Between “decrypted in memory” and “auto-cleared” is where most real-world leaks happen, and 30 seconds is a lifetime if you’ve pasted the address into a form that logs keystrokes.

The two practical fixes:

• Decrypt on an offline machine, write the address on paper, type it into the market form on a separate online device.
• Never decrypt more than you need: order notes should be short, and your decrypted clipboard should be treated as toxic until it’s cleared.

KeychainPGP supports Ed25519 + X25519 key pairs, which is modern and fine. It also imports ASCII-armored public keys by paste, which is what you want for vendor profile blocks. Verify the fingerprint out-of-band before you encrypt to it, knowing that on markets “out-of-band” often just means “the vendor’s own directory listing and PGP-signed forum post checked against each other.” Weaker than a phone call. Better than nothing.

The trust question, honestly

Most of this etiquette exists because the alternative is pretending escrow does more than it does. Escrow freezes funds during a dispute, but the dispute hinges on messages. If your order note was plaintext, unsigned, or addressed to a key you didn’t verify, the admin reading the dispute thread has less evidence than you think. If it was encrypted, signed, and addressed to a properly verified key, you have provable artefact, and the admins know it.

What you cannot fix: vendor key rotations you can’t verify, operators who enable features (registration-time PGP import) that quietly make your account depend on one secret, and scripts that claim end-to-end encryption while leaving metadata exposed. Note those limitations. Don’t pretend the tools are better than they are. Then sign your notes, encrypt your addresses, and save your ciphertext.

Research only. This piece documents common PGP practices as observed in marketplace scripts and public tools; it does not endorse or link to any live market.