Technical showcase · v0.LTP

Eight novel contributions
to post-quantum transfer.

LTP is not another file-sync layer or storage scheme. It is a transfer primitive built around a three-phase pipeline — Commit → Lattice → Materialize — that relocates the bandwidth bottleneck from the wire to the network, binds receivers cryptographically rather than by trust, and composes four standard hardness assumptions into a single transfer-immutability guarantee.

Sender payload
~1.3 KB
Constant. Independent of file size.
KEM primitive
ML-KEM-768
FIPS 203 · NIST Level 3
Adversary class
QTBE
Quantum Time-Bound Eavesdropper
Composite barriers
4
Chained for Theorem 8
// The eight contributions
01 // Pipeline

The Commit–Lattice–Materialize pipeline as a transfer primitive.

A three-phase architecture that reframes distributed encrypted storage as a transfer mechanism, not a storage system.

The core novelty isn't any single phase — it's the pipeline itself. Commit publishes a tamper-evident contract over the payload. Lattice disperses ciphertext shards across a commitment network. Materialize reconstructs only for an authorized receiver who can decapsulate the sealed key.

The result is a system where storage nodes are participants, not custodians; receivers are authenticated cryptographically, not contractually; and the wire payload between sender and receiver is decoupled from the entity being transferred.

What's new: no existing protocol uses this specific pipeline for transfer with constant sender-to-receiver bandwidth. Storage systems (IPFS, S3) use the pieces differently. Transfer protocols (SFTP, BitTorrent) don't compose them this way.
02 // Efficiency

O(1) sealed lattice key transfer.

The sender transmits a constant ~1,300-byte ML-KEM-768 sealed key to the receiver — regardless of whether the entity is 1 KB or 1 TB.

This is the bottleneck-relocation property. The bandwidth that traditionally scales with file size now scales with the commitment network, not the wire between sender and receiver. The sender-to-receiver payload is decoupled from the entity payload entirely.

In practical terms: a sender on a constrained uplink — a satellite, an embedded device, a mobile endpoint — can authorize the transfer of an arbitrary-sized entity with the same outbound cost as a single TLS handshake.

What's new: existing transfer protocols (SFTP, HTTPS, BitTorrent) all couple sender bandwidth to entity size. LTP architecturally separates authorization from delivery.
03 // Addressing

EntityID — content-addressed cryptographic identity.

A deterministic hash-based addressing scheme that binds an entity's identity to its cryptographic content.

An EntityID is derived from a fixed composition: payload digest, AEAD parameters, erasure parameters (n, k), sender signature key, and a transfer-context salt — all bound under a collision-resistant hash. Change any input and the identifier changes.

The result is an immutable, content-addressed identifier that any party can verify without trusting a central authority, a directory service, or the storage nodes themselves. Two parties holding the same EntityID can agree they are referring to bit-identical material.

Construction: EntityID = H( payload‖aead_params‖n‖k‖pk_S‖ctx )
Verification is a single hash check. Forgery reduces to collision resistance of H.
04 // Primitive

Sealed lattice key as a receiver-bound transfer token.

The lattice key is sealed to a specific receiver's public key — post-quantum secure, single-use, and non-transferable.

This is not generic key exchange. The sealed lattice key is constructed as a single-use authorization token: it can only be opened by the receiver whose ML-KEM public key was used during encapsulation, and once opened, it unlocks materialization for one specific EntityID under one specific context.

Re-broadcast, redirection, or replay attempts fail at the verification step before any storage proof is even requested. The token is the authorization — there is no separate access-control plane to compromise.

What's new: the lattice key serves three roles simultaneously — cryptographic key, authorization grant, and binding commitment. Existing systems separate these concerns; LTP composes them into a single primitive.
05 // Network

Commitment network shard distribution.

AEAD-encrypted payload, Reed-Solomon (n, k) shards, geographically distributed nodes, signed commitment record on an append-only log.

The payload is AEAD-encrypted, erasure-coded into n shards with reconstruction threshold k, and dispersed across the commitment network. A signed commitment record — naming the shards, their digests, and their holders — is appended to a tamper-evident log.

The novelty is the pairing: erasure coding is paired with the entity commitment scheme for transfer, not storage. Any individual shard is cryptographic noise; only a k-quorum, combined with a valid sealed lattice key, can produce the entity.

Properties: loss-tolerant up to n − k shards · no shard meaningful in isolation · commitment log is auditable independently of any storage node
06 // Adversary model

Quantum Time-Bound Eavesdropper.

A formal adversary model designed for transfer protocols operating under post-quantum threat assumptions.

Most quantum-resistance arguments are made about cryptographic primitives in isolation. QTBE applies a quantum-capable adversary specifically to the transfer context: the adversary records traffic at time t, gains quantum capability at time t + Δ, and attempts to break confidentiality, integrity, or authorization retroactively.

The model captures what makes "harvest now, decrypt later" a coherent threat — and what specifically is required to neutralize it for an in-flight transfer rather than for an encrypted file at rest.

QTBE captures: retroactive confidentiality break · authorization forgery against past transfers · commitment-record substitution under future quantum capability. Each is closed under LTP's composition.
07 // Theorem

Transfer immutability — composite security guarantee.

Four independent cryptographic barriers chained into a single guarantee: the received entity is bit-identical to what was committed.

Theorem 8 composes four standard hardness assumptions into one end-to-end property: any successful attack against transfer immutability reduces to breaking at least one barrier. The proof structure is game-based, and each reduction is concrete rather than asymptotic.

The composition itself is the contribution. Each barrier exists in the literature; chaining them through the CLM pipeline to produce a single composite transfer guarantee — with a formal proof — does not.

1
Collision resistance
EntityID forgery
2
EUF-CMA
commitment signature
3
IND-CCA
ML-KEM seal
4
AEAD security
payload confidentiality + integrity
08 // Verification

Storage proof verification at materialization.

Receivers cryptographically verify that commitment nodes are holding the correct shards — before and during reconstruction.

Trust in storage nodes is replaced with a verifiable property. When the receiver requests shards for materialization, the holding nodes return proofs that the shard they're serving matches the digest committed in the original record. Verification is cheap, parallel, and fails closed.

If a node is unavailable, lying about possession, or serving a corrupted shard, materialization fails at that shard — but reconstruction continues from the remaining k-quorum. The transfer either succeeds with full integrity or doesn't materialize at all.

The shift: commitment nodes are no longer custodians whose honesty must be assumed. They are participants whose contributions can be verified at point of use — turning trust into evidence.

Read the paper. Run the protocol.

LatticeWorks shares the full LTP technical paper and reference implementation under NDA with prospective licensees and design partners in regulated infrastructure.

Request the paper