A Privacy Protocol Using Ephemeral Intermediaries and a Rank-Deficient Matrix Power Function (RDMPF) (2512.23535v1)

Published 29 Dec 2025 in cs.CR and cs.NI

Abstract: This paper presents a private transfer architecture for the Internet Computer (ICP) that decouples deposit and retrieval through two short-lived intermediaries, with sealed storage and attested teardown by an ephemeral witness. The protocol uses a non-interactive RDMPF-based encapsulation to derive per-transfer transport keys. A public notice hint is computed from the capsule to enable discovery without fingerprinting the recipient's key. Retrieval is authorized by a short proof of decapsulation that reveals no identities. All transaction intermediaries are ephemeral and issue certified destruction intents and proofs, allowing a noticeboard to publish auditable finalization records. The design provides sender identity privacy with respect to the recipient, content confidentiality against intermediaries, forward secrecy for transport keys after staged destruction, verifiable liveness and finality. We formalize the basic interfaces, provide the security arguments for encapsulation correctness, hint privacy, authorization soundness and timeout reclaim. In terms of implementation, it has been recently brought into production on the ICP under the name ICPP. It has been subject to exhaustive testing and incorporates a few enhancements, focusing on the operational possibilities offered by ICP's technology. This work hence serves as a broad reference for the protocol now publicly accessible.

Abstract PDF Chat (Pro)

Summary

The paper presents a novel non-interactive key encapsulation using the RDMPF that secures sender identity privacy and unlinkability between deposit and retrieval phases.
It employs transient, self-destructing intermediaries and sealed storage to ensure content confidentiality and forward secrecy during asset transfers.
The protocol integrates rigorous cryptographic primitives with certified teardown, minimizing trust dependencies and resisting infrastructure-level threats.

A Privacy Protocol Based on Ephemeral Intermediaries and the RDMPF Construction

Protocol Architecture and Design Principles

The paper presents a transfer protocol for the Internet Computer (ICP) that employs two consecutive ephemeral intermediaries, sealed storage, and an independent ephemeral witness, achieving both sender-identity privacy and unlinkability between deposit and retrieval phases. The protocol leverages a novel non-interactive Rank-Deficient Matrix Power Function (RDMPF) for per-transfer key encapsulation, enabling AEAD-sealed content transfer with recipient discovery via a public hint computed from the capsule that is independent of the recipient’s key fingerprint.

The system is structured as follows:

Ephemeral deposit intermediary ( $I_1$ ) exclusively handles Alice’s (the sender’s) deposit and never interacts with Bob (the recipient). After deposit actions, $I_1$ self-destructs under witness attestation.
Storage canisters ( $C_1,\ldots,C_n$ ) persist sealed, opaque tuples and never interact directly with either sender or recipient.
Discovery is pull-based via a certified, append-only Noticeboard containing only the short public hint and associated metadata.
The ephemeral retrieval intermediary ( $I_2$ ) only handles Bob’s authorized retrieval and is destroyed after serving, with finalized destruction certified and published by a dedicated ephemeral witness ( $W$ ).
All ephemeral components are spawned with pairwise-distinct subnet preferences, blackholed controllers, and are scheduled for destruction within a short TTL.

Cryptographic Core: RDMPF Encapsulation

RDMPF formalizes a matrix-powered key encapsulation mechanism with non-trivial algebraic structure: sender and recipient keys are tuples of random matrix products over $Z_{p-1}$ , and the core shared secret is produced via composition of multiple RDMPF operations. The encapsulation yields a high-entropy secret which is then processed by HKDF and HMAC to form two per-transfer transport keys for AEAD and authentication.

The construction offers:

Non-interactive encapsulation: Alice encapsulates to Bob’s key using one-shot ephemeral keys; no interactive challenge/response is required.
Public discovery hint: The short $HINT = SHA3(\cdot)$ enables Bob to discover enveloped transfers without exposing his key or any recipient fingerprint in the public record.
One-time authorization: Bob authenticates retrieval using a hash of the derived per-transfer key, with the proof provided post-decapsulation.

The cryptographic security arguments hinge on the hardness of the underlying RDMPF problem (defined as cRDMPF and dRDMPF), alongside standard assumptions for HKDF, HMAC, SHA3, and AEAD. The paper establishes IND-CPA security for encapsulated payloads under these assumptions.

Security, Privacy, and Threat Model

The system provides explicit guarantees:

Sender-identity privacy: The recipient cannot link a transaction to the sender’s long-term identity; only a one-off ephemeral public key is revealed, and only if included by Alice.
Content confidentiality against infrastructure: No intermediary (including $I_1$ , $I_2$ , $C_i$ , or $W$ ) ever accesses the cleartext or any decryption material. The stored data is always in sealed AEAD envelopes, with secrets zeroed and ephemeral RAM wiped before teardown.
Path unlinkability: No single ephemeral canister can link sender to recipient. $I_1$ and $I_2$ do not overlap, and all routing/meta-data is infrastructure-to-infrastructure only.
Forward secrecy: All sensitive material (e.g., transport keys, ephemeral secrets) is destroyed and memory is deallocated upon completion, preventing latent recovery even with post-mortem analysis.
Recipient-private discovery: The public hint reveals nothing about Bob’s key, reducing to a brute-force preimage search over 256 bits.
Alice-only timeout reclaim: In the event Bob does not retrieve the asset before TTL, only Alice can reclaim, by presenting a pre-committed salt that is independent of any information observed by Bob.

The threat model assumes honest-but-curious intermediaries, robust cryptographic primitives, and acknowledges that full path linkage is only possible through active collusion of both key ephemeral intermediaries—an attack categorically out of scope by design.

The paper explicitly contrasts its model and privacy guarantees with those of Monero (ring signatures), Zcash (ZKPs), Tornado Cash (on-chain privacy), and Tor/Signal (routes and delivery meta-data), highlighting that no known "single-point" collusion yields sender-recipient linkage in this protocol.

Operational Flow and Integrity

The protocol’s implementation specifies a complete lifecycle:

The system setup phase publishes public parameters and registers pseudonymous long-term keys for recipients.
Each transfer spawns new ephemeral canisters for $I_1$ , $I_2$ , $C_1,\ldots,C_n$ , and $W$ with blackholed controllers, and all deployment is verifiable by certified context and code hashes.
Deposits are handled exclusively by $I_1$ , which writes an $Announce$ record to the Noticeboard and distributes the sealed payload; all actions are attested via the witness.
Retrieval requires Bob to provide a proof of authorizations, at which point $I_2$ orchestrates the destruction of all involved storage and intermediary canisters, with $W$ certifying each event and ultimately posting a $Finalize$ record.
After all ephemeral components are destroyed, the persistent system state consists solely of certified, minimally informative records on the Noticeboard.

Timeout/reclaim logic is rigorously specified such that, after TTL expiry if the retrieval is absent, only Alice (not Bob or any third party) can reclaim by demonstrating knowledge of a session-specific salt included at deposit.

Mathematical and Complexity Analysis

The RDMPF operation and key encapsulation are formalized algebraically, and the security theorems are proven within the standard cryptographic reduction paradigms. The protocol’s complexity is dominated by the $\dim^4$ modular exponentiations inherent to the RDMPF construction, with typical encrypted messages and token matrices consuming approximately 3–4KB per transfer at practical parameters ( $\dim=12$ ).

No persistent secrets are ever written to stable storage, and each interaction with the system is strictly bounded to freshly verified code and controlled lifespans, minimizing the risk of long-term side-channel or state compromise.

Practical and Theoretical Implications

Practically, the protocol’s deployment on the Internet Computer demonstrates that ephemeral, certified-execution architectures can enforce strong privacy properties in digital asset transfers, outstripping traditional mixer or ZK-based systems in terms of insensitivity to infrastructure compromise and absence of trusted-setup requirements. Architecturally, it is robust to platform-specific threats (e.g., caller principal tracking, ledger meta-data exposure, canister placement) by structural mitigations and rigid ephemeral canister management.

Theoretically, this protocol demonstrates the cryptographic viability of constructing unlinkable, non-interactive keyed transport without pairing-based or SNARK-based mechanisms, exploiting functional encryption as an algebraic secrecy layer and emphasizing the role of auditable teardown as a first-class privacy primitive.

Potential future work includes formal analysis of the RDMPF’s hardness in the post-quantum regime, the protocol’s extensibility to generalized multi-party or multi-hop asset flows, and optimization of computational complexity for large-scale deployment scenarios.

Conclusion

This protocol achieves strong sender anonymity, path unlinkability, forward secrecy, and privacy against infrastructure with a practical, certified ephemeral execution architecture. Its minimal trust model, auditable teardown, and systematic resistance to both cryptanalytic and platform-layer threats establish a rigorous foundation for privacy-enforcing asset transfers in decentralized networks. The RDMPF encapsulation, combined with canister lifecycles encoded in certified state, represents a substantive contribution both as a cryptosystem and as a model for ephemeral, verifiable privacy infrastructure (2512.23535).

PDF Markdown

Whiteboard

A Privacy Protocol Using Ephemeral Intermediaries and a Rank-Deficient Matrix Power Function (RDMPF)

Paper to Video (Beta)

Paper Prompts

Top Community Prompts

Explain it Like I'm 14

off on

Knowledge Gaps

off on

Glossary

off on

Practical Applications

off on

Conceptual Simplification

off on

Explain it Like I'm 14

What this paper is about

The paper explains a way to send something (like money or a message) privately on the Internet Computer (ICP). It splits the sending process into two separate parts—depositing and picking up—using short-lived helpers so no single helper ever sees both the sender and the receiver. It also uses a special math trick to create a one-time secret key, and it carefully proves why the whole system stays private and secure. This design is already built and running on ICP under the name ICPP.

The big questions the paper asks

How can Alice send to Bob so that outsiders can’t learn what was sent or who sent it?
How can the system keep even the delivery helpers from seeing the content?
How can Bob find his delivery without revealing his identity?
How can we be sure the temporary helpers actually delete their data when they’re done?
How can Alice get a refund if Bob never picks up?

How the system works (simple story)

Think of a private package drop-off using short-lived roles, like a pop-up post office that disappears after the job is done.

Deposit helper (I1): Like an intake clerk who receives a sealed package from Alice and stores it in several lockers.
Storage lockers (Cᵢ): Dumb lockers that just hold the sealed package; they never talk to Alice or Bob directly.
Noticeboard: A public board where a small “hint” (a code) is posted so Bob can discover his package without revealing who he is.
Retrieval helper (I2): Like a pickup clerk who checks Bob’s secret proof, fetches the package from a few lockers, gives it to Bob, and then disappears.
Witness (W): A security guard who records that the lockers and helpers did their jobs and were destroyed, then the guard also disappears.

Step by step:

Alice creates a sealed package using strong encryption and a special “capsule” that only helps Bob later. She gives the package and a short hint to I1.
I1 stores it in multiple lockers (Cᵢ), posts the hint on the public noticeboard, and then gets destroyed.
Bob scans the noticeboard for his hint and learns where to go for pickup (I2).
Bob proves he’s the right person using a tiny secret value he can compute locally. I2 checks this proof, collects the package from the lockers, delivers it to Bob, and then gets destroyed. Each locker used is destroyed too.
The witness W logs all these destructions and posts a final record, then W is also destroyed.

The math and crypto, in plain words

RDMPF (Rank-Deficient Matrix Power Function): Think of this like a special secret-mixing recipe. Alice and Bob can each run the same recipe with their own ingredients (their keys) and independently end up with the same secret number, without talking. That secret becomes the basis for the one-time keys that lock the package.
HKDF: A “key blender” that turns one good secret into multiple fresh keys for different jobs.
AEAD encryption: A locked box with a tamper-evident seal, so the content is private and any change is detected.
HMAC: A secret stamp that proves a message hasn’t been changed.
SHA3: A fingerprinting machine that turns any data into a fixed-size “hash” that’s hard to reverse.
Nonce: A one-time random salt that keeps outputs fresh and unlinkable.

Put simply: Alice locks the package with a one-time key that only Bob can recreate locally. The “hint” posted publicly is just a harmless fingerprint of the capsule, not Bob’s identity.

What did they test or prove?

The paper gives arguments (and some formal theorems) that the system has these guarantees:

Sender privacy from the recipient: Bob can’t tell who Alice is. Alice uses one-time identities.
Content confidentiality from helpers: Helpers only ever see sealed, unreadable data.
Unlinkable path: No single helper sees both the sender and the receiver, so they can’t connect Alice to Bob.
Forward secrecy: After the temporary helpers are destroyed, their keys are gone for good, so old transfers can’t be opened later.
Private discovery: The public hint doesn’t leak who Bob is. It’s just a 256-bit hash—guessing it is practically impossible.
Strong authorization: To pick up, Bob must show a tiny proof (a hash of a secret) that only the real recipient can compute by opening the capsule locally.
Timeout reclaim: If Bob never picks up, Alice can prove it’s her transfer and get a refund using a secret salt that only she knows.
ICP-specific protections: The design neutralizes ICP’s metadata leaks (like caller IDs and call graphs) by using one-time identities, separating roles, and never storing secrets at rest.

They also compare to other privacy systems (Monero, Zcash, Tornado Cash, Tor, Signal) and explain how this design reduces the need to trust any one piece of infrastructure. A single compromised helper can’t link Alice to Bob; it would take collusion between both I1 and I2 to break that unlinkability.

Why it matters

Practical privacy: It’s a concrete, working way to move value or data privately on ICP.
Minimal trust: No single helper can break privacy; keys are short-lived and destroyed.
Auditable end: A witness posts final records so users can check that everything was cleaned up.
Safer discovery: Bob finds his transfer without revealing who he is.

Limitations to keep in mind:

If both deposit and retrieval helpers collude, they could link sender and receiver.
The platform controls where helpers run (their “subnets”). The system prefers to spread them out, records where they landed, and lets users enforce policies, but perfect placement isn’t guaranteed.

Takeaways

Separate the journey: Split deposit and pickup so no one helper sees the full path.
Use short-lived parts: Destroy helpers and their secrets after the job to protect old transfers.
Prove, don’t trust: Keep public, verifiable records of who stored what and who was destroyed.
Keep discovery private: Let the receiver find their package via a harmless public hint.
Make refunds safe: Only the original sender can reclaim if time runs out.

Overall, the paper delivers a clear, tested blueprint for private transfers on ICP that balances strong cryptography, careful system design, and real-world deployability.

View Paper Prompt View All Prompts

Knowledge Gaps

Unresolved Gaps and Open Questions

The paper leaves several aspects uncertain, underspecified, or unexplored. Future work could address the following concrete gaps:

RDMPF hardness and foundations:
- Precisely define the cRDMPF assumption and provide reductions to well-studied problems or a thorough cryptanalytic assessment; include attack models (e.g., known-ephemeral/known-public-key attacks, chosen-capsule attacks).
- Prove (rather than state) the RDMPF composition law (Lemma “Composition Law for RDMPF Outputs”) or clearly document the conditions under which the Hecht2025 result applies and its security implications.
- Quantify the conditional min-entropy of $Z$ given all public material and the capsule, and bound it in terms of parameter choices; validate via analysis or empirical tests.
- Map parameter choices ( $p\approx2^{192}$ , $\dim\in[8,24]$ , rank constraints) to concrete security levels; justify $p$ and $\dim$ against known attack complexities (including sub-exponential discrete-log algorithms and small-subgroup risks due to $p-1$ factorization).
Post-quantum security:
- Assess RDMPF’s susceptibility to quantum attacks (e.g., Shor’s algorithm on $\mathbb{Z}_p^\ast$ exponents) and outline a post-quantum instantiation or an alternative KEM with equivalent protocol properties.
Formal specification completeness and clarity:
- Provide an unambiguous, complete specification of the capsule contents, the “context” field, and all data structures ( $,$ , $E_{\mathrm{inner}}$ ), as the current text contains formatting/notation corruption and omissions that hinder implementability.
- Explicitly define all message flows and who decrypts what in Phase 4 (ambiguity around whether $I_2$ decrypts $or only verifies a value inside it). - AEAD usage and nonce management: - Specify the AEAD construction (algorithm, nonce size, associated data) and how nonces are generated, guaranteed unique, and bound to session identifiers to prevent reuse and cross-session malleability. - Analyze misuse resistance (e.g., accidental nonce reuse) and integrity guarantees in the presence of adversarial canisters and network races. - Hint privacy and linkability: - Analyze whether$ HINT=SHA3(\text{capsule}) $permits cross-session linkability (e.g., through structural or length patterns in the capsule or repeated recipient keys), and whether auxiliary timing on the Noticeboard degrades recipient privacy. - Evaluate threat of large-scale Noticeboard mining (e.g., guessing epk_S or enumerating capsules) and set concrete rate-limiting or proof-of-work defenses. - Authorization soundness beyond IND-CPA: - Provide a formal treatment of the$ h=SHA3(K_{\mathrm{auth}) $authorization, including bounds against offline preimage attacks on$ K_{\mathrm{auth} $and resistance to replay or reflection attacks across sessions. - Clarify whether$ K_{\mathrm{auth} $is ever revealed to$ I_2 $or any intermediary and how$ h $is transported and verified inside$ or $E_{\mathrm{inner}}$ .
Timeout reclaim correctness and races:
- Analyze race conditions between reclaim and ongoing retrieval near TTL, including ordering guarantees, idempotence, and rollback safety if $\mathsf{Finalize}$ posts after a reclaim attempt.
- Provide a formal proof that revealing $(R,\alpha)$ at timeout does not leak $K_{\mathrm{enc}$ or $K_{\mathrm{auth}$ (HKDF domain separation and extractor guarantees), and quantify any cross-protocol leakage.
- Detail denial-of-service resilience: can an adversary block finalization to force reclaim? What incentives or protocol checks mitigate griefing?
Destruction proofs and liveness/finality guarantees:
- Specify the cryptographic format and verification procedure for DestructIntent and DestructProof, and how clients can verify actual destruction (vs. only intent) given platform constraints.
- Analyze platform-level rollback/snapshot risks: can a malicious Factory or subnet restore destroyed canister state; what detectable signals or attestations are available?
- Define how clients detect and respond to partial destruction (e.g., some $C_i$ fail to destroy) and how this affects finality.
Subnet placement and collusion:
- Quantify the security impact of co-location when pairwise-distinct subnets cannot be guaranteed; provide acceptance policies with measurable risk thresholds.
- Move collusion of $I_1$ and $I_2$ from “out of scope” to a mitigable risk: explore adding more intermediaries, threshold witnesses across multiple subnets, or verifiable shuffles to reduce two-party collusion breaking unlinkability.
- Introduce a verifiable random selection mechanism (e.g., VRF-based or randomness beacon) for witness and component placement that the Factory cannot bias.
Censorship resistance and availability:
- Specify $t$ -of- $n$ quorum thresholds, failure handling, and re-spawn logic when $C_i$ are censored or unresponsive; quantify retrieval success probability under adversarial $C_i$ fractions.
- Define timeouts, retry policies, and back-off for $I_2$ when gathering from $C_i$ , and analyze the impact on liveness under heavy load or targeted DoS.
CSRN privacy and binding:
- Analyze whether $K_{\mathrm{transit}=SHA3(\mathsf{deposit\_id}\,\|\,\mathsf{alice\_principal}\,\|\,\mathsf{nonce})$ leaks metadata or facilitates linkability (e.g., deposit_id reuse), and whether including $\mathsf{alice\_principal}$ undermines sender privacy if principals are re-identifiable.
- Clarify delivery path and AEAD nonce uniqueness for CSRN encryption and decryption; specify associated data binding to session context.
Ledger mixing properties:
- Provide a formal anonymity set analysis for the mixer pool, including split distributions, timing obfuscation, and subset-sum reconstruction hardness with concrete parameters.
- Quantify correlation risks across deposits/withdrawals (amounts, timing, routing) and set mixer policies that achieve specified anonymity levels under realistic adversarial observations.
Noticeboard robustness:
- Define protections against Noticeboard spam and poisoning (e.g., authenticated postings, rate limits, stake-based publishing) and the operational cost of Bob’s scanning at scale.
- Explore privacy-preserving discovery (e.g., PIR, private filters, or batched hint checks) to reduce Bob’s exposure and metadata leakage during scans.
Implementation transparency and auditability:
- Publish or reference audited, open-source Wasm code and deterministic build pipelines; define how clients discover “expected” code hashes and trust their provenance.
- Detail the memory zeroization procedure, its timing, and platform guarantees (e.g., no swap/paging of sensitive data) to substantiate “no data at rest survives.”
Side-channel and metadata leakage:
- Provide a formal leakage model for ICP call-graph, timing, and principal creation, and quantify residual privacy loss after mitigations (ephemeral principals, infra-only calls).
- Assess timing, cache, and resource-usage side channels within canisters (e.g., data-dependent compute) that could leak capsule or payload properties.
Usability and key management:
- Specify how users manage ephemeral principals securely and ensure they are truly unlinkable over time; address recovery from client loss or device changes.
- Define UX flows for reclaim, error handling, and out-of-band confirmations (e.g., CSRN) that do not leak identities or create new correlators.
Correctness under edge cases:
- Detail behavior when multiple transfers target the same recipient concurrently (hint collisions, queueing, retrieval order) and how the protocol avoids cross-session confusion.
- Analyze duplicate or replayed deposits and retrievals, and define idempotent state transitions at the Router.
Functional encryption section:
- Clarify whether the idealized two-input functional-encryption primitive in Section “Functional Encryption” is required by the protocol or only exploratory; if required, specify a concrete instantiation or remove the dependency.
- If retained, define anchored key issuance, trust distribution of $\mathsf{msk}$ , and how FE interacts with RDMPF without leaking scalars.
Economic and performance characteristics:
- Provide empirical measurements on ICP (latency, cycles cost per transfer, failure rates) and scalability analysis under realistic workloads; define target SLAs for liveness and finality.
- Model fee structures, retry margins, and adversarial cost for DoS, and propose parameter choices that balance cost and resilience.
Compliance and abuse prevention:
- Discuss policy controls for preventing misuse (e.g., illicit funds) while preserving privacy, and how destruction proofs/finalization logs could support audits without compromising identities.

Addressing these points would significantly strengthen the security assurances, clarity, and deployability of the proposed protocol.

View Paper Prompt View All Prompts

Glossary

AEAD: Authenticated Encryption with Associated Data; a symmetric encryption scheme that provides both confidentiality and integrity for a message. "Only $=AEAD_{}(\textsf{payload})$ is handled in transit."
Announce: A public record published to the Noticeboard to enable discovery of a deposit without revealing identities. " $I_1 \rightarrow Noticeboard$ : $Announce$ $\{\mathsf{idx},HINT,\mathsf{rendezvous\_token},\mathsf{code\_hash}(I_1)\}$ ."
Blackholed controllers: A deployment configuration where a canister’s controller is irreversibly set to an unmanageable principal, preventing code or state changes. "Self-controlled canisters, blackholed controllers, and one-shot destruct timer ( $\le$ TTL)."
Canister: On ICP, a smart-contract unit that bundles executable code and persistent state. "instances (computational units) are known as canisters, which are smart contracts that bundle both code and their persistent state."
Canister-Signed Receipt Nonce (CSRN): A 32-byte, canister-generated nonce used to bind a transfer and provide mutual confirmation without revealing identities. "Each transfer generates a 32-byte Canister-Signed Receipt Nonce (CSRN) for binding and receipt purposes."
Capsule: The public KEM artifact containing ephemeral keying material and tags from which transport keys are derived. "A public notice hint is computed from the capsule to enable discovery without fingerprinting the recipientâs key."
Certified state: State whose integrity is guaranteed by ICP’s certification, enabling clients to verify recorded identifiers, placement, and code hashes. "Spawns fresh $I_1, I_2, C_1,\ldots,C_n, \mathcal{W}$ per transfer, recording their IDs and subnets in certified state."
cRDMPF: The computational hardness assumption for the RDMPF operation, asserting infeasibility of recovering secrets from public parameters. "Assume cRDMPF (computational hardness of $RDMPF(P,W,Q)$ without the secret scalars),"
Cycles Minting Canister: ICP system component that converts ICP tokens into cycles used to pay for canister execution. "Invokes Factory to spawn ephemeral infrastructure, and converts user-provided ICP to cycles via the Cycles Minting Canister."
Decapsulation: The recipient-side operation of deriving the shared secret from the capsule in a KEM scheme. "Retrieval is authorized by a short proof of decapsulation that reveals no identities."
DestructIntent: An attested intent to destroy an ephemeral component, recorded and later certified by a witness. " $I_1 \rightarrow \mathcal{W}$ : $\mathsf{DestructIntent}\{\mathsf{id}(I_1),\mathsf{nonce},\mathsf{deadline}\}$ ;"
DestructProof: A certified proof that an ephemeral component has been destroyed, used for auditable finalization. " $\mathcal{W}$ records $\mathsf{DestructProof}(I_1)$ before itself being destroyed (the protocol leaves no witness)."
Ephemeral canister: A short-lived canister instantiated for a single transfer and destroyed after its role completes. "Ephemeral instances are blackholed, hence they cannot self-destroy."
Ephemeral principal: A temporary identity used by a party to avoid linkage across calls or transfers. "Alice (via an ephemeral principal) submits a sealed package $\{HINT,,\}$ to an intermediary $I_1$ ."
Factory (canister): The permanent canister that deterministically spawns the ephemeral infrastructure and certifies its context. "Factory spawn -- Spawn fresh $I_1, I_2, C_1,\ldots,C_n, \mathcal{W}$ with pairwise-distinct subnets and $\mathsf{subnet}(\mathcal{W})$ distinct."
Finalize: A certified record posted after observed destructions to indicate auditable completion. " $W$ certifies storage commits and all staged destructions ( $I_1$ , served $C_i$ , $I_2$ ) and finally publishes a $Finalize$ record on the $Noticeboard$ , then is destroyed via Factory."
Functional encryption (FE): A cryptographic paradigm that allows computing specific functions on encrypted data without revealing the data itself. "We assume an idealized two-input functional-encryption primitive that reveals, for selected indices, the pointwise product of entries of two encrypted matrices"
HKDF: HMAC-based Key Derivation Function used to derive transport and MAC keys from the RDMPF secret. " $(,) \leftarrow HKDF\!\big(Z;\ \textsf{info}=\text{``rdmpf-kem''},\ \mathsf{salt}=\mathsf{nonce}\big)$ "
HINT: A short, public hash of the capsule enabling recipient-side discovery without revealing identities. "Bob scans the $Noticeboard$ for his short public hint $HINT=SHA3()$ and obtains the rendezvous token for $I_2$ ."
HMAC: Hash-based Message Authentication Code used to compute integrity tags tied to context. "$\mathsf{tag} \leftarrow \mathsf{HMAC}_{K_{\mathrm{auth}(\mathsf{context}).$"
IND-CPA: Indistinguishability under Chosen-Plaintext Attack; a standard encryption security notion ensuring ciphertext indistinguishability. "the AEAD used for $$ is IND\textup{-}CPA secure."</li> <li>Internet Computer (ICP): A decentralized compute platform (blockchain) on which the protocol is implemented. "This paper presents a private transfer architecture for the Internet Computer (ICP)"</li> <li>Mixer pool: A shared fund pool that splits and randomizes transfers to resist correlation attacks. "Upon sealing, funds move to a shared mixer pool via randomized chunking, breaking amount-based and timing-based correlation."</li> <li>Non-Interactive Key Agreement (NIKA): A key agreement where parties derive the same key without interaction, based on RDMPF outputs. "we define a Non-Interactive Key Agreement (NIKA) as"</li> <li>Noticeboard: A public, certified log that hosts Announce and Finalize records for pull-based discovery. "Public, certified log for $Announce $and$ Finalize $. Enables pull-based discovery via$ HINT$; contains no identities."</li> <li>Onion routing: A network privacy technique that layers encryption across a path of relays to conceal content and origin. "Tor -- Onion routing hides content, but exit nodes see destinations and directory authorities see topology."</li> <li>PRF: Pseudorandom Function; a function indistinguishable from random to efficient adversaries, used to argue non-leakage. "By PRF security, it leaks nothing about $K_{\mathrm{auth}$."</li> <li>Quorum: The minimum number of storage canister replies required for retrieval to proceed. "set quorum ($t $-of-$ n$ or replication);"</li> <li>RDMPF: Rank-Deficient Matrix Power Function; a matrix-based operation underpinning the non-interactive key agreement. "A Privacy Protocol Using Ephemeral Intermediaries and a Rank-Deficient Matrix Power Function (RDMPF)"</li> <li>Rendezvous token: A token posted with Announce that directs the recipient to the correct retrieval intermediary. "listings containing $HINT $and the associated$ \mathsf{rendezvous\_token} $for$ I_2$."</li> <li>Ring signatures: A signature scheme that hides the actual signer among a group of possible signers. "Ring signatures hide the true input among decoys, but nodes can log transactions, IP addresses, and timing."</li> <li>Router: The permanent user-facing canister orchestrating deposit lifecycle and payments. "Router (Permanent)"</li> <li>Sealed package: An opaque tuple containing the hint and encrypted payload that intermediaries store and relay. "Alice (via an ephemeral principal) submits a sealed package $\{HINT,,\} $to an intermediary$ I_1$."</li> <li>Sealed Sender: A design that conceals sender identity from intermediaries, adapted here from Signal’s approach. "The Sealed Sender approach (hiding sender identity from intermediaries) is analogous to Signal's design, applied here to the transfer rather than messaging context."</li> <li>Subnet: A partition of the ICP network where canisters are placed, used to reduce common-mode risks via diversification. "Spawn fresh $I_1, I_2, C_1,\ldots,C_n, \mathcal{W}$ with pairwise-distinct subnets"</li> <li>Sybil adversary: An attacker that creates or controls many nodes to amplify traffic-analysis or correlation capabilities. "A Sybil adversary controlling sufficient nodes can apply traffic analysis to degrade unlinkability."</li> <li>Timeout reclaim: A refund mechanism that allows only the sender to reclaim funds after a TTL if the recipient has not retrieved. "Timeout Reclaim (Sender-Funded Refunds)"</li> <li>TTL: Time-to-live; a policy parameter bounding the lifespan of ephemeral components and the reclaim window. "Protocol call -- Alice requests: Send $A $ICP to$ pk_R=(P_R,Q_R)$ with policy and TTL."</li> <li>WebAssembly (Wasm): A portable binary instruction format; verified Wasm code is installed on canisters. "Install verified WebAssembly (Wasm);"</li> <li>Witness: The ephemeral canister that certifies commits and destructions and publishes the finalization record. "Witness $\mathcal{W}$ (Ephemeral)"

View Paper Prompt View All Prompts

Practical Applications

Immediate Applications

The following applications can be deployed now using the protocol and implementation described (ICPP is live on ICP).

Private value transfers on ICP (finance, software)
- Use the dual-intermediary dead-drop to send ICP tokens or tokenized assets without revealing sender identity to the recipient and without exposing content to intermediaries.
- Tools/products/workflows: wallet integration that creates ephemeral principals, “Private Transfer” button, Router-based mixing and subaccount management, client verification of Factory code hashes, Noticeboard discovery UI.
- Assumptions/dependencies: RDMPF hardness, AEAD/HKDF/HMAC/SHA3 security, fresh nonces, user adherence to ephemeral principals, platform-certified Noticeboard, non-collusion of I1 and I2, and acceptance that ledger amounts/timing are mitigated via mixing and randomized splits.
Sealed digital content handoff for credentials, files, and keys (software, cybersecurity, enterprise)
- Transfer secrets (API keys, config bundles, license files) with RDMPF-derived transport keys and ephemeral storage; intermediaries only handle opaque tuples.
- Tools/products/workflows: client-side KEM encapsulation library, “sealed handoff” SDK, destroy-on-delivery workflow with auditable Finalize records.
- Assumptions/dependencies: AEAD confidentiality, witness attestations recorded and verified, client zeroization of local secrets after retrieval.
Anonymous tip lines and whistleblower drops (media, public sector, civil society)
- Deposits via I1 with recipient-private discovery using HINT; sender identity hidden from recipient; intermediaries see only opaque data; witness certifies destruction.
- Tools/products/workflows: public Noticeboard portal with HINT search, hardened client for ephemeral principal use, CSRN receipts to confirm delivery without identities.
- Assumptions/dependencies: honest-but-curious infrastructure, non-collusion of I1 and I2, platform placement policies recorded and verified by clients.
Escrow-like conditional transfers with sender-only timeout reclaim (commerce, marketplaces)
- Use the reclaim mechanism (HKDF-derived R with sender-held salt α) to ensure only the sender can refund after TTL if Finalize is absent.
- Tools/products/workflows: “Private Escrow” product with TTL, automatic Router authorization, reclaim UI tied to sender’s ephemeral principal.
- Assumptions/dependencies: secure client storage of α, correct Router state machine, AEAD IND-CPA for ciphertext, HKDF separation for reclaim key material.
Private NFT drops and claim tokens (web3, entertainment)
- Announce listings with HINT; recipients discover pull-side without revealing their identity; retrieval authorized by SHA3(K_auth).
- Tools/products/workflows: airdrop manager using ICPP, recipient-side Noticeboard watcher, claim workflows.
- Assumptions/dependencies: adequate entropy in capsule → HINT, non-fingerprintable recipient keys via HINT, client verification of Finalize events.
Compliance-friendly destruction attestation and data minimization (governance, policy compliance, enterprise IT)
- Witness W certifies storage commits and staged destruction; Finalize provides auditable records showing no data retained beyond session.
- Tools/products/workflows: compliance dashboards aggregating DestructProof events, policy engine enforcing cross-subnet distinctness, acceptance policies on code hashes and placement.
- Assumptions/dependencies: certified state integrity, verifiable Wasm code hashes, blackholed controllers, recorded subnets.
Privacy-preserving messaging attachments or secure side channels (communications, software)
- Pair messaging apps with ICPP to deliver attachments or access tokens using RDMPF KEM and ephemeral storage; authorization via short proof of decapsulation.
- Tools/products/workflows: messaging client plugin generating epk_S per transfer, HINT-based discovery, single-use K_auth proofs.
- Assumptions/dependencies: freshness of nonce and epk_S, client-side derivation correctness, avoidance of re-use across transfers.
Private rewards distribution, micro-bonuses, and payroll splits (HR, finance)
- Use the Router’s mixing pool and randomized chunking to break timing/amount correlation when distributing funds privately to employees or contributors.
- Tools/products/workflows: payroll service integration with subaccount sealing, randomized splits, Noticeboard monitoring for finalizations.
- Assumptions/dependencies: sufficient pool size and randomness for effective mixing, recipients capable of Noticeboard discovery.
Mutual receipts via CSRN without identity exposure (legal, compliance, software)
- Both parties receive the same canister-signed receipt nonce, confirming delivery while preserving anonymity.
- Tools/products/workflows: “CSRN viewer” for receipt verification, API hooks returning CSRN on successful retrieval.
- Assumptions/dependencies: secure AEAD transit encryption for CSRN during deposit, proper binding to deposit_id and prevention of replay.
Academic testbed for privacy architectures and ephemeral computing (academia)
- Use ICPP as a live platform to study ephemeral infrastructure, hint privacy, path unlinkability, and verifiable finalization in production conditions.
- Tools/products/workflows: experiment harnesses around Factory/Router/Witness, controlled placement policies, traffic analysis studies under honest-but-curious intermediaries.
- Assumptions/dependencies: access to ICP subnets and certified state, transparent code hashes, reproducibility of spawn proofs.

Long-Term Applications

The following applications require further research, scaling, standardization, cross-platform support, or integrations beyond ICP.

Cross-chain private transfers and sealed content handoff (finance, software)
- Port the dual-intermediary and witness-attested teardown to other blockchains or distributed platforms lacking ICP’s canister model.
- Potential products: “Ephemeral Privacy Layer” bridging ICP with Ethereum/Solana via relayers; cross-chain Noticeboard.
- Assumptions/dependencies: availability of ephemeral compute and certified state on target platforms, attestation equivalents, or trusted execution environments.
RDMPF KEM standardization and formal cryptanalysis (academia, standards)
- Advance RDMPF beyond the current hardness assumptions with deeper proofs, parameter recommendations, and interop APIs; explore post-quantum security.
- Potential products: open-source RDMPF libraries, RFCs/standards, formal verification toolkits.
- Assumptions/dependencies: sustained cryptanalysis efforts, community review, potential hardware acceleration for matrix operations.
Regulated privacy with AML/KYC-compatible attestations (policy, fintech)
- Combine recipient-private discovery with zero-knowledge attestations that signal compliance without revealing identities (e.g., selective disclosure).
- Potential products: “Compliant Private Transfers” modules, zk-based eligibility tokens, regulated Noticeboard policies.
- Assumptions/dependencies: regulator acceptance, robust zk proof systems, policy frameworks aligning with data minimization.
Healthcare data exchange with expiring retrieval and audit trails (healthcare)
- Use witness-attested destruction for ephemeral medical record transfers; CSRN as confirmation; sender-only reclaim for time-limited access.
- Potential products: “Ephemeral Health Data Rooms,” secure referral handoffs, compliance dashboards for HIPAA/GDPR data minimization.
- Assumptions/dependencies: sector-specific compliance integration, client-side secure storage, institutional acceptance and audit integration.
Supply-chain secret handoffs (manufacturing, IoT)
- Deliver firmware signing keys or device credentials via sealed dead-drops; destruction proofs reduce key residency risk.
- Potential products: “Ephemeral Key Courier” service, device-side RDMPF client libraries.
- Assumptions/dependencies: IoT client capability for KEM and Noticeboard discovery, secure device storage, operational policies for subnets.
Decentralized and diversified witness selection (software, governance)
- Move from a single ephemeral witness to threshold witnesses or rotating committees across distinct subnets to reduce common-mode risks.
- Potential products: “Witness DAO,” threshold attestation protocols, multi-party Finalize records.
- Assumptions/dependencies: protocol changes for selection randomness, committee coordination, stronger anti-collusion guarantees.
Privacy-preserving sealed-bid auctions and procurement (finance, energy, public sector)
- Use RDMPF-based encapsulation for sealed bids; reveal winners with auditable finalization; preserve bidder anonymity until necessary.
- Potential products: auction platforms with Noticeboard-based discovery and Finalize audits.
- Assumptions/dependencies: fair reveal protocols, anti-collusion rules, economic incentives aligned with privacy.
Civic processes: secure voting logistics tokens and private credential delivery (civic tech)
- Distribute expiring access tokens (e.g., poll-worker credentials) via ephemeral infrastructure; destruction proofs serve as compliance artifacts.
- Potential products: “Ephemeral Civic Access” toolkits, governance-ready Noticeboards.
- Assumptions/dependencies: broader threat models, integration with identity and eligibility systems, legal frameworks.
Enterprise Data Minimization-as-a-Service (enterprise IT, compliance)
- Productize ephemeral storage and witnessed teardown as a managed service embedded into workflows (contracts, negotiations, M&A data rooms).
- Potential products: expiring data rooms with CSRN confirmations, policy engines enforcing placement and code hash checks.
- Assumptions/dependencies: organizational adoption, integration with document management and IAM, cross-subnet placement policies.
IoT/Robotics ephemeral credential issuance and control (robotics, energy)
- Issue one-shot control tokens or configuration secrets to devices; retrieval proofs confirm activation; attested destruction reduces long-term exposure.
- Potential products: device orchestration platforms with sealed dead-drops, control-plane privacy layers.
- Assumptions/dependencies: device-side KEM support, secure random generation, resilient Noticeboard access.
Education and training on privacy architectures (education, academia)
- Build curricula and labs around ephemeral intermediaries, hint privacy, and audited finalization; compare against Tor, Zcash, Monero, Signal.
- Potential products: teaching modules, simulation tools, comparative security exercises.
- Assumptions/dependencies: accessible testnets, reproducible deployments, code openness and documentation.
Post-quantum evaluation and migration paths for RDMPF (academia, standards)
- Analyze RDMPF under quantum adversaries; design migration strategies if needed; benchmark against PQ KEMs for transport secrecy.
- Potential products: PQ-ready RDMPF variants, hybrid KEM strategies, parameter guidance.
- Assumptions/dependencies: sustained research, community consensus, performance trade-off analyses.

A Privacy Protocol Using Ephemeral Intermediaries and a Rank-Deficient Matrix Power Function (RDMPF) (2512.23535v1)

Summary

A Privacy Protocol Based on Ephemeral Intermediaries and the RDMPF Construction

Protocol Architecture and Design Principles

Cryptographic Core: RDMPF Encapsulation

Security, Privacy, and Threat Model

Operational Flow and Integrity

Mathematical and Complexity Analysis

Practical and Theoretical Implications

Conclusion

Whiteboard

Paper to Video (Beta)

Paper Prompts

Top Community Prompts

Explain it Like I'm 14

What this paper is about

The big questions the paper asks

How the system works (simple story)

The math and crypto, in plain words

What did they test or prove?

Why it matters

Takeaways

Knowledge Gaps

Unresolved Gaps and Open Questions

Glossary

Practical Applications

Immediate Applications

Long-Term Applications

Open Problems

Continue Learning

Authors (1)

Collections

Tweets

YouTube

A Privacy Protocol Using Ephemeral Intermediaries and a Rank-Deficient Matrix Power Function (RDMPF) (2512.23535v1)

Sponsor

Summary

A Privacy Protocol Based on Ephemeral Intermediaries and the RDMPF Construction

Protocol Architecture and Design Principles

Cryptographic Core: RDMPF Encapsulation

Security, Privacy, and Threat Model

Operational Flow and Integrity

Mathematical and Complexity Analysis

Practical and Theoretical Implications

Conclusion

Whiteboard

Paper to Video (Beta)

Paper Prompts

Top Community Prompts

Explain it Like I'm 14

What this paper is about

The big questions the paper asks

How the system works (simple story)

The math and crypto, in plain words

What did they test or prove?

Why it matters

Takeaways

Knowledge Gaps

Unresolved Gaps and Open Questions

Glossary

Practical Applications

Immediate Applications

Long-Term Applications

Open Problems

Continue Learning

Related Papers

Authors (1)

Collections

Tweets

YouTube