Verify a Recipient Before You Seal a File

Before you seal a sensitive file, verify the recipient's receive address through a channel an attacker is unlikely to control. A receive address is a public key, not a name. If you encrypt to the wrong key, the wrong key holder may be able to open the file — and the person you meant to reach may not.

This is the most common human failure in encrypted workflows. The cryptography can be flawless and the send can still be wrong, because nothing about a string of characters proves whose key it is. Encryption answers "who can open these bytes?" It does not answer "did I pick the right person?"

What is a receive address?

A receive address is an encryption public key the sender uses to seal a record. With CardanoWall it comes in two forms:

age1... — a classical X25519 receive address.
age1pqc... — a hybrid post-quantum receive address.

The sender seals to the recipient's published address. The recipient opens the record with the matching private key, which is derived from their Identity Seed. The address is meant to be shared; the private key and the seed must stay secret. (For more on what an address is and how recipients hand one out, see what is a receive address.)

Why does verifying the key matter so much?

Because public keys are not identities.

Anyone can send you a string that looks like a receive address. Anyone can paste a key next to a familiar display name. The string itself proves nothing about who controls the matching private key — only that some key holder does. An attacker who slips you their own address gets to read everything you seal "to" your contact, while your contact gets nothing.

For a throwaway test file, that may not matter. For legal evidence, incident data, personal information, unpublished work, or whistleblower material, verify the key before you seal. The address book exists to make that verification stick: you check the key once, save it, and reuse the saved entry instead of re-pasting a string you have to trust again every time.

What counts as a good verification channel?

Use a path the attacker is unlikely to control, and confirm the key over a channel separate from the one that delivered it. Reasonable options, roughly in order of strength:

An in-person handoff (for example, scanning a QR code together).
A phone call to a number you already know, reading the key fingerprint aloud.
A .well-known key page on the recipient's official domain.
A DNS TXT record on that domain.
A signed profile linked from the recipient's official site.
An existing end-to-end encrypted conversation you already trust.
An organization-approved key directory.
A printed key fingerprint delivered through a process you trust.

The right method depends on what you are sending. For high-value files, confirm over two independent channels — a key emailed to you and read back on a phone call is much harder to forge than either alone.

What is not enough on its own?

A familiar name is not enough. Treat these as unverified until a second channel confirms them:

A key that arrives in a brand-new email thread.
A direct message from an account you have not verified.
A screenshot of a key.
A public profile with no trusted link back to the person.
An address forwarded to you by a third party.
A "here's my new key" message with no second-channel check.

Attackers concentrate on the moment of key exchange, because it is the one step where a substituted key looks completely normal. Once a wrong key is saved, every future send can quietly keep going to the wrong place.

How should you use the address book?

Save the key after you have verified it, never before. For each trusted contact, the address book records:

A display name.
The contact's Ed25519 signing public key (the identifier that ties their records to them).
An age1... receive address, if they have one.
An age1pqc... post-quantum receive address, if they have one.
How you verified the key, and when.
Free-form notes — write down exactly how you checked it.

Later, when you compose a sealed record, pick the contact from the address book instead of pasting an address again. That turns one careful verification into many safer sends. For a walkthrough of building one, see create your address book and how the address book works.

Should you prefer the post-quantum address?

For files that may stay sensitive for many years, yes — use the post-quantum address when the recipient offers one.

A hybrid age1pqc... address is much longer than a classical one, but it protects against an attacker who records sealed ciphertext today and decrypts it later with a future quantum computer ("harvest now, decrypt later"). If a record only needs to stay private for the near term, a classical age1... address is usually enough.

Whichever you choose, the rule does not change: verify the address first. A post-quantum key you did not verify is no safer than a classical one you did not verify.

What if the recipient rotates keys?

Verify the new key as if it were a new contact. Do not overwrite a saved receive address just because a message claims it changed — that is exactly the shape a key-substitution attack takes. Confirm the new key through a trusted channel, update the entry, and note why it changed.

For teams and organizations, key rotation should be announced in predictable places: an official domain, a signed profile, or a documented internal process. If you suspect a key was compromised, stop sealing to the old address immediately and wait for the new one to be confirmed.

What does a sealed record reveal on-chain?

Not a readable recipient list. A Label 309 sealed record wraps the content key into one encrypted slot per recipient, then shuffles them, so the public record carries no plain "recipient" field. The Inbox finds records meant for you by trial-decrypting each slot locally with your own keys. What an observer can see is that a sealed record exists, when it was published, and how many slots it has — never who the recipients are.

That recipient-blindness protects on-chain privacy, but it does nothing for key verification. The chain hides who you sealed to; it cannot check that you sealed to the right key. Picking the correct address is still entirely the sender's job. And note the limit on the other side: sealing keeps the plaintext encrypted for key holders, but it does not guarantee anonymity, and any recipient can leak the plaintext once they have decrypted it. (For what a proof can and cannot establish, see what a proof does not prove.)

The short version

Good encryption plus a bad key check is still a bad send. So:

Verify a receive address before sealing anything sensitive, ideally over two channels.
Save verified keys in the address book; note how each one was checked.
Re-verify when a key changes — treat the new key like a brand-new contact.

The cryptography is the easy part. The verification is the part you own.