TDF vs Traditional File Encryption: What Each One Enforces

Traditional file encryption and Trusted Data Format (TDF) both protect a file with strong symmetric cryptography, and they enforce different things. Traditional file encryption enforces key possession: anyone holding the key can decrypt, anywhere, forever, with no further check. TDF enforces an access policy bound to the object: the data encryption key is wrapped to a key access server, and every decrypt requires that server to evaluate the requester's attributes against the policy carried inside the file. Conventional encryption answers who holds the key. TDF binds the question of who should hold it to the object itself.

TDF and traditional file encryption compared

What traditional file encryption does well

Traditional file encryption is mature, fast, well understood and widely implemented, and it should not be replaced where its properties are sufficient.

AES-GCM, OpenPGP and S/MIME have decades of cryptanalytic scrutiny behind them, implementations in every major platform, and hardware acceleration on ordinary CPUs. Full-disk and object storage encryption defend against theft of the medium at essentially no operational friction. None of these require an online service at the moment of use, so none can fail because a service is down.

Traditional file encryption is also correct where the recipient set is small, stable and trusted, and revocation is not a requirement. An encrypted archive sent to a known counterparty with an out-of-band passphrase is a sound control for that case, and adding a policy service to it adds cost without adding assurance.

TDF depends on traditional file encryption. A TDF payload is encrypted with a conventional authenticated symmetric cipher, as set out in What Is Trusted Data Format: A Technical Reference. The format changes how the key is governed, not how the bytes are protected.

What TDF adds

TDF adds three properties that key possession alone does not provide.

A policy that travels with the object. The TDF manifest carries a policy object naming the attributes required for access, bound to the data encryption key by a keyed hash. Editing the policy breaks the binding, and the key access server rejects the request. Copying the file copies the policy.

A decision at every open. Because the data encryption key is wrapped to a key access server rather than delivered to the recipient, opening the file is a request. A policy decision point evaluates attribute-based access control (ABAC) against the requester's current attributes. A recipient who was authorized last week and is not authorized today is denied today.

A record of access attempts. Every decrypt attempt reaches the key access server, so the originating organization sees who asked for what, when, and what the answer was. Conventional encryption gives the originator no visibility once the file leaves. The mechanism is described in How TDF Enforces Access Policy at Decrypt Time.

Can TDF protect data outside the enterprise boundary

TDF keeps ciphertext governed outside the enterprise boundary, and it does not control plaintext after an authorized release. Both halves of that sentence are load-bearing.

The governed half is real. A TDF object sitting on a partner's file share, in a personal cloud account, on removable media, or in an attacker's exfiltration archive is ciphertext with a policy attached. Opening it requires a successful request to the key access server. The organization that produced the file therefore retains a decision point over data it no longer possesses, which is not true of a conventionally encrypted file whose key has been distributed. That property is why data-centric controls change the economics of exfiltration, discussed in why ransomware does not work on policy-bound data.

The uncontrolled half is equally real. Once a request is authorized and the client decrypts, plaintext exists on that endpoint. TDF does not prevent a screenshot, a photograph of the screen, a retype, a copy into an unprotected file, or an authorized user forwarding what they legitimately read. Claims to the contrary describe endpoint controls layered on top, not the format.

What each approach costs to operate

Traditional file encryption costs key distribution and rotation. Those costs are well understood and largely one-time per recipient relationship. The failure modes are lost keys, shared passphrases and stale keys held by former recipients.

TDF costs the operation of a key access server, integration with an identity provider, and ongoing governance of the attribute model. The attribute model is the part organizations underestimate. Attributes that are wrong, stale or inconsistently assigned produce denials that block work or approvals that should not have been granted, a prerequisite covered in data classification as the foundation of zero trust.

TDF also introduces an availability dependency. A file that cannot reach its key access server cannot be opened. Fail-closed defaults are the correct security posture and a real operational constraint in disconnected, tactical and air-gapped settings, which require a key service inside the enclave.

When traditional file encryption remains the right choice

Traditional file encryption is the better answer in several cases, and saying so is not a concession.

• Where the data must be openable with no reachable service, including archival storage intended to outlive the systems that created it.
• Where the recipient set is small, static and trusted, and revocation is not required.
• Where the protection requirement is media theft rather than access governance, which is what full-disk and storage-layer encryption address.
• Where the counterparty cannot run a TDF-capable client and no browser-based path is acceptable.
• Where regulatory language names a specific cipher or container format and accepts nothing else.

Most organizations end up running both. Storage and transport encryption defend the layers they defend, and TDF governs the objects whose access needs to remain decidable after distribution.

Limits both approaches share

Neither approach protects plaintext after decryption, compensates for wrong classification of the underlying data, or defends an endpoint already compromised at the point of use, because a compromised endpoint sees what the authorized user sees. Neither removes the need for key custody discipline.

Both also face the same long-horizon threat. Ciphertext captured today can be stored against future cryptanalytic capability, which is why key wrapping in either model needs a migration path to post-quantum key encapsulation.

How Lattix implements the difference

Lattix applies cryptographic enforcement to TDF objects. The policy decision point (PDP) evaluates ABAC across subject, device, environment and geography, purpose of use, network posture, risk, and data-object attributes, and returns a signed, short-lived decision carrying allow or deny, the reasons, the policy version hash, and the object identifier. The policy enforcement point (PEP) acts at decrypt time, so enforcement survives whatever service is in the path. Defaults are fail-closed and revocation propagates to deny. Content identifiers and Merkle-tree lineage records make decision history queryable. Key wrapping supports post-quantum key encapsulation with ML-KEM-768 and ML-KEM-1024, and the same posture deploys across cloud, regional hub, tactical edge and air-gapped environments.

Frequently asked questions

How does TDF compare with traditional file encryption?

Traditional file encryption enforces key possession: whoever holds the key decrypts, with no further check. TDF wraps the data encryption key to a key access server and binds an access policy to the object, so every decrypt is an authorization request evaluated against the requester's current attributes. Both use the same underlying symmetric cryptography. They differ in who decides and how often.

Can TDF protect data outside the enterprise boundary?

TDF keeps the ciphertext governed outside the boundary, because opening the object requires a successful request to the key access server named in its manifest. A copy on a partner's share or in an exfiltration archive stays unreadable without an authorized decision. TDF does not control plaintext after an authorized user decrypts, so screenshots, retyping and photography remain outside its scope.

Does TDF replace full-disk or transport encryption?

TDF does not replace them. Full-disk encryption defends against theft of the medium, transport encryption defends the wire, and TDF governs access to the object itself. The three protect different layers and are commonly deployed together. A TDF object stored on an encrypted volume and transferred over TLS carries three independent protections.

Can encrypted files be revoked after they have been sent?

Conventionally encrypted files cannot be revoked once the key is distributed; the only remedy is re-encryption with a new key and redistribution to the remaining recipients. TDF objects can be revoked by updating the policy or the requester's attributes, because the next decrypt request is evaluated fresh. Copies already decrypted to plaintext are outside the reach of either approach.

Is TDF slower than conventional file encryption?

Payload encryption and decryption use conventional authenticated symmetric ciphers, so bulk throughput is comparable. The added cost is one round trip to the key access server per object opened, plus the identity and attribute lookups behind it. For workloads opening very large numbers of small objects, key request volume is the dimension to plan for.

What happens to a TDF file if the key access server is unavailable?

The decrypt request fails and the payload stays ciphertext. Defaults are fail-closed, so unavailability denies rather than permits. Deployments that must operate disconnected run a key service inside the enclave or provision keys in advance for a defined scope and period. Archival use cases that must outlive any running service are usually better served by conventional encryption.