Sending the decryption key separately: safe key exchange for data deliveries

The three rules of safe key exchange#

Safe key exchange follows three rules: a different channel from the data, a separately verified recipient and a limited lifetime. Each rule closes a specific failure. A different channel means one compromised mailbox does not expose both. A verified recipient means someone who intercepts a shipment cannot simply ask for the passphrase. A limited lifetime means a key found later in an old message no longer opens anything.

The rules apply whether the data ships on an encrypted drive, sits in a cloud bucket or moves as an encrypted archive. They also apply in reverse: if a buyer sends back an acceptance report containing sample records, that file deserves the same care.

Four acceptable methods for sending a key#

Four methods suit data deliveries: a one-time secret link, a verified phone or video readout, encryption to the recipient's public key and a time-limited grant in a key management service. What they have in common is that the key never sits in the same message, folder or package as the data. A shared item in a business password manager can work as a variant of the first method, provided the share expires and access is logged.

For recurring deliveries to a technical team, public-key encryption is usually the cleanest choice. The recipient generates a key pair with OpenPGP-compatible software and keeps the private half; you never hold or transmit a secret they could lose in transit, and a new delivery needs no new conversation about passwords.

Methods to avoid#

The methods to avoid all put the key within reach of anyone who gets the data, or release it to someone nobody verified. Most of these shortcuts happen under time pressure, when a recipient says the drive has arrived and asks for the password right away. Agreeing the release method in writing before anything ships removes the temptation to improvise.

Scan the package itself before release as well, because keys and credentials can end up inside delivered files, especially code and configuration exports. Gitleaks, an MIT-licensed scanner for passwords, API keys and tokens, is one common check. Its maintainer stated in May 2026 that it is feature complete and will receive security patches only, so confirm a tool is still maintained before adopting it.

• 1The passphrase in the same email as the download link or tracking number.
• 2A passphrase inside the drive box, on a label or in a README file in the package.
• 3A key posted in a shared chat channel the whole project team can read.
• 4A company-wide password reused across deliveries or buyers.
• 5A text message to whoever just received the courier notice, with no verification.
• 6A spreadsheet of delivery passwords on a shared drive.

Verifying the recipient before you release the key#

Recipient verification means confirming identity through contact details you already hold, not details supplied in the request. Use the named data contact and notice details from the license agreement, and call or message the recipient through that route.

Tie the release to a confirmed delivery. Ask the recipient to confirm the package arrived intact, quote the drive serial number or archive name, and match checksums against the manifest you sent separately. If anything does not match, hold the key and investigate before releasing it.

Treat urgency as a warning sign. A request that arrives from a new address, asks to change the named recipient or pushes for release before checksums are confirmed is exactly what an impostor would send. Pause, call the contract contact and confirm before anything else happens.

A release sequence for each delivery#

A release sequence turns the three rules into eight fixed steps that run the same way for every delivery. Splitting duties is a sensible default: one person prepares and ships the data, and another holds and releases the key. That separation makes it harder for a single mistake or a single compromised account to expose both.

• 1Generate a unique, random passphrase or key for this delivery only.
• 2Encrypt the drive or archive and record the method in the delivery record.
• 3Ship or publish the data, and send the manifest with checksums separately.
• 4Wait for the recipient to confirm receipt and matching checksums.
• 5Verify the recipient through the contact details in the contract.
• 6Release the key using the agreed method.
• 7Confirm successful decryption, then expire, rotate or revoke the key.
• 8Log the release time, method, sender and recipient in the custody record.

Illustrative: a consulting firm delivers a project archive#

Illustrative: a fictional management consulting firm licenses a prepared archive of proposal reviews, staffing decisions and internal project retrospectives exported from SharePoint and its CRM. The IT manager encrypts the archive on a drive and ships it to the buyer's data lead named in the license agreement.

When the drive arrives, a coordinator on the buyer's side asks for the password by replying to the tracking notice. The IT manager instead asks for the data lead's public key, verifies its fingerprint on a call to the phone number in the contract, and sends the passphrase encrypted to that key. The buyer confirms checksums and decryption, the firm rotates the passphrase, and the release is logged with the delivery record.

How SourceX approaches key handling#

SourceX treats key exchange as part of the Delivery step of the SourceX five-step transaction. The supplier approves the release and the delivery method, and SourceX agrees the key release method and the named recipient with both sides before anything ships, so nobody improvises when a drive arrives.

The key release becomes part of the release authorization in the SourceX Evidence Packet, alongside provenance, licensing rights, permitted use and the privacy record. A clear record of who released which key, when and how lets either side answer questions later without relying on memory.