PGP Encryption and Message Verification on Torzon

On Torzon, PGP solves a problem that centralised systems usually answer with a username and a password: how do you know a message really came from the person you expect, and how do you keep a shipping address readable only by that person? A market does not have the luxury of a trusted company server that quietly restores access or vouches for identities. Any account could be someone else, and any plaintext address could be read by whoever controls the wire between you and the site. PGP gives both sides a way to operate without that central authority.

The tool is not one single feature; it is two habits used together. When you encrypt a message to a vendor’s public key, you create a payload that only the holder of the matching private key can open. When you verify a signed message, you confirm that the author controlled a specific private key at the time of writing. Neither action requires the market to stand in the middle and promise that everything is fine.

A useful mental model is a lockbox with two keys that are not equal. The public key is like an open padlock handed out freely: anyone can click it shut on a message. The private key is the only thing that opens that specific lock. Because the private key never leaves the owner’s device, the system does not depend on the market’s good behaviour to protect the contents.

1. Vendor publishes a public keythe market profile or signed note contains the key material
2. Buyer imports or pastes the keyno private key is involved
3. Buyer encrypts the addressthe plaintext is replaced by ciphertext
4. Vendor decrypts locallythe private key stays on the vendor’s machine
5. Buyer checks vendor signaturesdisputes rely on a provable chain of authorship

The core benefit is non-repudiation without custody. A signed message from a vendor’s key gives a buyer evidence that the same key holder accepted an order, changed a condition, or made a promise. A signed message from a buyer’s key does the same in reverse. The market may host the dispute, but it does not have to be trusted as the sole source of truth about who said what.

On Torzon this matters most at three moments: before you send a shipping address, when you receive a payment confirmation or shipping update, and when a disagreement about an order begins. In each case, PGP turns “the site says” or “the vendor claims” into something the user can inspect directly. The next section looks at why the two-key design makes that possible.

Think of an asymmetric keypair as a box with two different locks that fit the same lid. The public key locks the box; only the private key can open it. This is why sharing your public key is harmless: it only gives someone the ability to seal a message for you, not to read anything sent to you.

Encryption and signing are not the same operation. Encryption uses the recipient’s public key to hide a message from everyone except the private-key holder. Signing uses the sender’s private key to prove that the message really came from that sender, and that nobody altered it in transit.

A newcomer should verify one thing first: that the key fingerprint you hold for a trading partner or market address matches the one they use in the signed message. Fingerprints are compact strings derived from a public key. If even one character differs, you are not talking to the same key — stop and re-check through a separate channel.

Public key

a shared cryptographic value used to encrypt data meant for its owner or to verify that owner’s signatures

Private key

a secret value that decrypts data sent to its owner and creates signatures only the owner can make

Fingerprint

a shortened, fixed-length representation of a public key used for reliable key comparison

Signing

the act of proving message authorship and integrity with a private key

Encryption

the act of transforming a message so that only the holder of the matching private key can read it

When you enter a shipping address into an order form on Torzon, that field is not simply stored and shipped. The interface encrypts it locally, using the vendor’s public key, before the encrypted blob is transmitted. What gets protected is the plaintext address itself — the name, street, city, postal code, and any delivery notes. The encryption means that whoever later views the message in transit or on the server side sees ciphertext, not a readable address.

Think of the vendor’s public key as a one-way mail slot: anyone can push a sealed envelope through it, but only the vendor can open the envelope with their private key. The buyer does not need any key material from the vendor beyond the public key itself, and the vendor never sees the buyer’s own encryption setup. This is the point: the protection is directional. It protects the address from everyone except the holder of the matching private key.

What failure actually looks like

If PGP is not used correctly, the failure is usually silent at first. The buyer may believe the address was protected because the order form accepted input and proceeded normally. But here is what actually goes wrong. If the buyer copies an address into a plaintext note field instead of the encrypted field, the message travels without any protection. If the buyer encrypts to the wrong public key — for example, an old key or a key that does not belong to the vendor — then the ciphertext is useless to the intended recipient and the address is not protected in any meaningful way. If the buyer pastes their own public key into the encryption step, they have not protected the address from the vendor’s side; they have only made it unreadable to the person who needs to ship the order.

1. Buyer pastes address into the encrypted field The address exists as plaintext only on the buyer’s own screen
2. Buyer encrypts to the vendor’s current public key The plaintext is replaced by ciphertext that only the vendor’s private key can reverse
3. Encrypted message is sent The message passes through relays and server logic as unreadable ciphertext
4. Vendor decrypts locally The address becomes readable only at the vendor’s side, where the private key stays

In a dispute, the question is rarely what happened — it is what can be demonstrated to a neutral party. A signed PGP message changes that calculation. When someone claims ownership of an order, a wallet, or a conversation thread, the verifier does not need to trust the person’s story. They check the signature against the same public key that was recorded when the order was created. If it matches, the claim is tied to a keypair, not to a mood or a screenshot.

An unsigned claim sits at the bottom of the evidentiary ladder. Screenshots can be edited. Plaintext can be pasted from anywhere. A login session can be borrowed or stolen. But a signature that verifies against a known public key proves one narrow, powerful thing: at some point, someone with access to the corresponding private key produced this exact message. That is a much smaller claim than “I am the vendor” — and it is the only claim escrow can act on without inventing trust.

In practice, dispute resolution works by comparing keys over time. If a vendor’s public key has been stable across many successful orders, and the disputed message verifies against that same key, the signature carries weight. If the key changed shortly before the dispute, or the message comes from a key never used on the order thread, a careful reviewer treats it as noise. Continuity of key identity is the closest thing to reputation that cryptography can provide.

The strongest dispute evidence is therefore a chain: the order references a key, the encrypted address used that key, and the later signed statement verifies against the same key. Break any link and the chain loses its force. That is why signing early — at the moment of agreement — matters more than signing convincingly after something has gone wrong.

Trust in a PGP key is not something you import once and freeze. It is built from repeated observation. The first time you see a vendor’s public key, treat it as an unverified claim. The second time, if it matches, the claim gains a little weight. By the tenth or twentieth interaction, a mismatch becomes far more suspicious than a match is reassuring — because an attacker who controls the channel once can swap the key, but an attacker who controls it consistently over weeks is running a different and much more expensive operation.

Think of a public key like a face you recognize in a crowded room. One glance is easy to spoof. But the way someone moves, speaks, and responds over many encounters builds a picture that is hard to fake all at once. Key continuity works the same way: you are not proving the key belongs to a specific person. You are noticing whether it stays the same person across time.

What a key mismatch actually tells you

A changed key is not automatically an attack. Vendors rotate keys, lose access to old key material, or rebuild their setup after operational changes. The mistake is to silently accept the new key and continue. The correct response is to stop, ask for an explanation through a separate channel if one exists, and check whether the vendor has posted a signed transition message using the old key. If the old key cannot or will not sign the change, you have no cryptographic continuity — only a stranger claiming to be the same person.

• Observation over time
• Cross-checking channels
• Signed transitions
• Unsigned replacement

Key continuity

the practice of comparing a public key against previous sightings to detect substitution ;; Signed transition

A useful habit is to write down a short fragment of the fingerprint — not the whole thing, just enough characters to make accidental collision unlikely. Then, when you see the key again, compare your fragment first. Humans are bad at comparing long random strings side by side. We are much better at noticing that the six characters we remembered are suddenly absent.

The trap to avoid is treating any single source — a profile page, a forum post, a vendor’s own listing — as permanent truth. Sources can be edited, hijacked, or mirrored. What resists that kind of manipulation is your own record. The strongest trust is not louder confidence from one place. It is quiet consistency across many.