--- title: Private Exchange category: Sharing icon: 🔐 sort_order: 22 excerpt: Independently enroll two participants, commit encrypted files, and reveal both packages only after both commitments are recorded. slug: private-exchange canonical_url: https://basaltnotes.com/guides/private-exchange markdown_url: https://basaltnotes.com/guides/private-exchange.md --- # Private Exchange Private Exchange is a two-participant, end-to-end encrypted exchange. It is useful when both people should commit a file before either can retrieve the other submission—for example, protected document swaps, sealed proposals, reciprocal disclosures, credentials delivered with a file, or other time-bounded exchanges. The organizer coordinates the exchange but does not control either participant's private key or access credential. ## How the process works 1. **The organizer creates the exchange.** In **Private Exchange**, enter a title, two participant names and email addresses, an expiration period, and a policy. The general policy accepts a broad range of files. The protected-PDF policy requires a PDF, a password that opens it, and final commitment confirmation. 2. **Each participant receives a separate enrollment email.** The link contains a one-time claim credential that expires after 24 hours. It is not a finished participant access link and contains no private decryption key. 3. **Each participant claims their own slot.** The participant's browser generates a P-256 keypair and a new bearer credential. Only the public key and a hash of the bearer credential are sent to Basalt. The one-time email claim is then invalid. 4. **Both participants enroll before either deposits.** This lets each browser encrypt specifically for the other participant's public key. 5. **Each participant reviews and commits one package.** Basalt validates the selected policy in the shipped browser client, encrypts the file and optional password locally with AES-256-GCM, and uploads only ciphertext. Commitment is irreversible unless the exchange later expires or both participants authorize cancellation. 6. **The second commitment releases both packages atomically.** A database lock records the commitment, release, and signed audit events together. Neither participant can retrieve the other package while only one commitment exists. 7. **Each participant retrieves and decrypts locally.** Basalt issues a capability valid for 60 seconds and limited to the other participant's single ciphertext object. The browser checks the ciphertext digest, decrypts it locally, checks the recovered plaintext digest, and records decryption confirmation. 8. **Either participant can export the receipt bundle.** Receipts include database timestamps and an Ed25519-signed hash chain so they can be checked outside the dashboard. ## What Basalt can and cannot see Basalt receives the participant names and email addresses, public keys, hashed bearer credentials, exchange policy, ciphertext metadata and hashes, client policy evidence, lifecycle state, and signed audit events. Private Blob storage contains the encrypted packages. Basalt does **not** receive either participant's private decryption key, plaintext file, or packaged password/access code. The organizer does not receive either participant's bearer credential or private key. Email delivery services and automated link scanners may see the short-lived claim URL. A claim can be used only once, expires after 24 hours, and is replaced with credentials created in the claiming browser. ## Commitments, cancellation, and expiration - Before either participant enrolls or commits, the organizer can cancel the exchange or rotate an unclaimed invitation. - After enrollment begins, participant identities, recipients, public keys, policy, and deadline are fixed. - After the first commitment, the organizer cannot unilaterally cancel or replace a submission. Both participants must request cancellation, or the exchange must expire. - A committed submission cannot be replaced. - Expired and canceled exchanges enter a purge workflow. Basalt marks deletion complete only after private Blob deletion succeeds; failed deletion remains retryable. Do not treat an invitation email as proof that the intended person opened it. Confirm participant identity through an appropriate independent channel when the exchange is consequential. ## Protecting access and recovering from loss The participant access credential and private key live in the URL fragment after enrollment. URL fragments are not sent in normal HTTP requests, but browser history, screenshots, clipboard tools, extensions, device backups, or anyone with access to the full URL may expose them. - Use a trusted, updated browser on a device you control. - Do not forward or paste the enrolled participant URL into messages or support requests. - Keep the enrolled tab or bookmark available until retrieval and receipt export are complete. - If the enrolled URL or private key is lost, Basalt cannot recreate it or decrypt the package. Support and the organizer cannot recover it. - If an unclaimed email link is exposed, ask the organizer to rotate the invitation before it is claimed. - If an enrolled participant URL is exposed, stop using the exchange and request cancellation when possible. Create a new exchange with fresh credentials. ## Policy choices **General file exchange** supports broader workflows while retaining the same enrollment, encryption, atomic release, and receipt protocol. The organizer sets the allowed types, extensions, maximum size, password requirement, and final confirmation requirement within Basalt's hard limit. **Protected PDF** verifies in the shipped participant browser that the selected file has a PDF signature, rejects opening without a password, and opens with the supplied password. Because the server intentionally cannot decrypt the file, this result is participant-supplied policy evidence rather than independent server inspection. The signed receipt records the evidence that accompanied the commitment; it does not prove what an altered client actually executed. ## Receipt terminology - **Enrolled** means a participant claimed their slot and registered a public key and hashed bearer credential. - **Committed** means Basalt atomically accepted an immutable ciphertext package and its supplied integrity metadata. - **Released** means both commitments exist and retrieval is now authorized. - **Retrieval requested** means Basalt issued a short-lived download capability. It does not prove that a download completed. - **Decryption confirmed** means the participant's browser reported successful authenticated decryption and a recovered digest matching the peer's committed plaintext digest. Download the signed receipt bundle before the exchange expires if you need a portable record.