Encrypting Dataset Deliveries: PGP, age and Cloud KMS Key Exchange

What transport encryption leaves exposed

Transport encryption protects bytes on the wire, not the file once it lands. TLS and SSH (the layer under SFTP) stop interception between endpoints, and storage encryption such as SSE-S3 protects disks from physical theft, but anyone holding valid credentials to the landing zone reads plaintext [3]. File-level encryption closes that gap: the file stays ciphertext in the drop folder, in backups, in a misconfigured bucket and in a forwarded download link until a holder of the private key decrypts it.

Use the three layers for different threats:

Managed-file-transfer documentation recommends PGP for sensitive data, especially where a channel is not itself encrypted [2]. For the yes-or-no question on transit, see is licensed data encrypted in transit; this page covers methods and key lifecycle.

OpenPGP with GnuPG: the interoperable default

OpenPGP is the safest choice when the supplier already runs managed file transfer, because nearly every MFT product, SFTP gateway and ETL tool speaks it. As of October 2026, the current specification is RFC 9580 (July 2024), which obsoletes RFC 4880 and defines the packet formats for encryption, signatures and key management. OpenPGP is hybrid: a random session key encrypts the file symmetrically, and that session key is encrypted to each recipient's public key.

Pin parameters in writing rather than accepting tool defaults. A published credit-bureau transfer standard is a useful template: RSA keys of at least 2048 bits, separate encryption and signing subkeys, mandatory key expiry, and AES256 as the symmetric cipher [1]. Modern GnuPG also supports Curve25519 keys, but confirm the supplier's MFT stack can read them before you switch away from RSA.

Common failure modes on large files:

• Encrypt-only, no signature. Without --sign, you cannot prove the supplier produced the file. Require sign-then-encrypt and verify with gpg --verify against a pinned fingerprint.
• Compression on already-compressed data. Parquet with Zstandard or gzipped JSONL gains nothing from OpenPGP compression; set --compress-algo none to save CPU on multi-gigabyte files.
• ASCII armor on bulk files. --armor inflates size by about a third; use binary .gpg output for data.
• Version skew. Older tools may not handle newer packet versions or AEAD modes; agree the profile (key algorithm, cipher, AEAD on or off) with a test file before production.

age vs GPG for file encryption

age is a better fit than GPG when both parties control their tooling and want fewer moving parts. It has no web of trust, no keyring and few options: recipients are short X25519 public keys (or SSH keys), and files are encrypted in streamed chunks, so multi-terabyte archives do not need to fit in memory. The trade-offs are that age does not sign files and is rarely built into commercial MFT products.

If you use age, pair it with a separate signature (for example minisign or ssh-keygen -Y sign) over the manifest, and keep the manifest and checksum process as the integrity record. Choose OpenPGP when an auditor or the supplier's security team expects it; choose age for engineer-to-engineer pipelines you control end to end.

Cloud KMS envelope encryption for bucket deliveries

Envelope encryption is the right pattern when the delivery is object storage to object storage. Each file is encrypted locally with a data key; the data key is encrypted under a KMS key that never leaves the provider's HSMs, and the encrypted data key travels next to the ciphertext. Decryption requires a KMS Decrypt call, so access becomes an IAM decision you can audit in CloudTrail and revoke by changing the key policy or grants.

For supplier deliveries, the buyer usually owns the KMS key and grants the supplier's role kms:Encrypt or kms:GenerateDataKey only, never kms:Decrypt. Combine the key policy with the cross-account bucket grant pattern AWS documents [4], and see cross-account cloud bucket delivery for the bucket side. Bind an encryption context such as {"dataset":"support-tickets","delivery_id":"2026-10-01"} so each ciphertext is tied to one delivery and appears in audit logs.

Two cautions. SSE-KMS alone is storage encryption: anyone with s3:GetObject plus decrypt permission reads plaintext, so it is not a substitute for client-side encryption when the bucket is shared. And caching data keys across many files reduces KMS calls but enlarges what one leaked key exposes.

Choosing a method: decision table

The right method follows from who controls each endpoint and what the supplier's stack already supports.

Exchanging and verifying keys with a supplier

Key exchange is a common weak point in delivery encryption. A public key emailed by an attacker looks exactly like a real one, so the fingerprint must be confirmed over a second, independent channel.

Illustrative example: invented to show structure; it does not describe an available dataset.

Key exchange record (one per delivery relationship)

delivery_relationship: support-ticket-history-feed
method: openpgp            # openpgp | age | kms-envelope
recipient_key:
  owner: buyer-data-intake
  algorithm: rsa4096        # or ed25519/cv25519, x25519 (age)
  fingerprint: "A1B2 C3D4 E5F6 0718 293A  4B5C 6D7E 8F90 1A2B 3C4D"
  expires: 2027-10-01
  verified_out_of_band: video call, fingerprint read aloud, 2026-09-22
supplier_signing_key:
  fingerprint: "9F8E 7D6C 5B4A 3928 1706  F5E4 D3C2 B1A0 9F8E 7D6C"
  verified_out_of_band: signed letter on file, 2026-09-23
cipher_profile: AES256, no compression, binary output
signature_required: true
test_file_exchanged: 2026-09-24 (decrypted and verified)
rotation: annual, or on staff change or suspected compromise
revocation_contact: security@ (both parties)
end_of_term: destroy decryption keys and log destruction

Practical rules: publish encryption keys from an account you control, never from a personal laptop; keep private keys in a hardware token or a secrets manager on the decryption host; and run a test file through the full path before any real data moves.

Key rotation for recurring data feeds

Rotation for recurring feeds should be scheduled, overlapping and logged. Set key expiry dates (the standard above makes expiry mandatory [1]), publish the new key and fingerprint before the old one expires, and accept both for one delivery cycle so an in-flight batch never fails decryption. With KMS, enable automatic rotation of key material; previous versions remain available to decrypt older ciphertext.

Record the key fingerprint or KMS key ARN in each delivery's manifest, alongside the version ID. That lets you answer "which key protects the 2026-07 snapshot?" when you later version licensed datasets or move to incremental deliveries. Rotate immediately, outside the schedule, when a person with key access leaves or a host is compromised.

Key destruction at the end of a license term

Destroying the keys is how you make retained ciphertext unreadable when a license ends. If every copy, backup and snapshot of a dataset is encrypted under one key, scheduling that key for deletion (KMS enforces a waiting period) or securely destroying the private key renders those copies unrecoverable without hunting down each object. This only works if no plaintext copies exist, so keep decrypted working sets inside controlled, logged environments.

Document the destruction: key ID, date, method and approver, filed with the license record. Pair it with the deletion and correction process for recurring deliveries so retracted records are handled before keys are retired.

How this fits a licensed data purchase

Encryption choices belong in the delivery terms you negotiate, alongside formats and schedules covered in the dataset delivery hub and the broader AI data buyer guides. SourceX sources operational datasets from US companies on request and manages the licensing and ongoing purchases; each dataset is rights-reviewed and delivered under a license that defines records, uses, term and delivery. Delivery runs through private, access-controlled workflows, never email attachments, and only after an executed agreement and supplier approval. More detail is in how SourceX handles data security and the trust center, or you can describe the data you need.

Source licensed data with secure delivery terms

SourceX finds US businesses that hold the data you describe, assesses data and licensing permissions, and agrees pricing and allowed uses in a license before anything is transacted. Personal details are removed or replaced before delivery, and a request does not guarantee a match. Start a buyer request.