Advising: A Critical Finding in the PIE Non-Custodial Compute Model
The model removes the operator's ability to decrypt anything once a job ends. The device still encrypts to an unverified public key published by the one component the model designates as untrusted.
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
I have been building systems for 25 years, and I love building things that are intentionally designed and operationally lean, carrying only as much of a vector as earns its weight.In that approach, minimising what I store of a user's data has always made sense to me, for reasons that go past the obvious one. Sovereignty of their data matters. Underneath it is something simpler: things belong where they belong. Most of what I build is processing, and a processing architecture has no business operating as anything else. Holding a record it never needed is a vector that earns nothing. Treating that as an optimisation, rather than as a compliance exercise, is what keeps the design honest — and a system built that way tends to land in good standing with regulation on its own, because there is very little of it left to regulate.So when Mary Camacho's announcement came across my feed on X, I read her architecture the way I read my own. She had published the core of it into the public record under a Creative Commons licence, at the level of detail an engineer would need to rebuild it, and she was direct about the prior art it stands on.Working through the sequence, I placed an adversarial entity inside the server and followed what it could reach. It could outpace the worker.Nearly all of the work that followed happened as a voice conversation — over 30 voice notes, thinking out loud and testing the concern from different angles until it either held or fell apart.What I noticed: the device encrypts to whoever writes the claim record first#
The disclosure specifies the order of operations directly. The worker claims the job and publishes its key, and only then does the device encrypt:The device's side of that agreement is specified with equal precision:— §2.1, Data flow (per job)
- Worker → coordination: poll and claim the job (write-once, first-wins), publishing the worker's public key.
- Device ← coordination: poll, retrieve the worker's public key, derive the shared secret, encrypt the payload.
The device, on learning the worker's public key, performs its own X25519 exchange and an ML-KEM encapsulation against the worker's key, producing its own public contribution (X25519 public key ‖ ML-KEM ciphertext) and the shared secret.— §4.2, Binding to the worker lifecycleOn learning. Across 19 pages there is no signature over the worker's ephemeral public key, no certificate, no attestation the device evaluates, and no pre-shared secret. The absence is deliberate and presented as a strength: the model gates decryption on no attestation document, TPM quote, or measured-boot artifact, and it keeps no pre-provisioned worker secret.So the device encrypts its payload to whatever public key is sitting in the claim record, with no means of telling a legitimate worker's key from anyone else's. Any party able to write a claim first becomes the party the device encrypts to, and the confided payload decrypts in their hands.
flowchart TB
subgraph BEFORE["Before: as published"]
direction TB
A2{"Who claims first?"} -->|Real worker| A3["Genuine key"]
A2 -->|Any other writer| A4["Attacker key"]
A3 --> A5["Device encrypts to it"]
A4 --> A5
A5 --> A6["Key holder can read"]
end
subgraph AFTER["After: signed key"]
direction TB
B2{"Signature valid?"} -->|Yes| B3["Verified worker key"]
B2 -->|No| B4["Refuse, retry"]
B3 --> B5["Only true worker reads"]
end
A6 ~~~ B2Copy sourceThe cryptography is sound and the introduction is unauthenticated#
The attacker breaks nothing. X25519 and ML-KEM-768 both work exactly as specified. The attacker supplies a key and becomes a legitimate party to the agreement.This is unauthenticated key agreement, and its failure mode is the oldest result in the field. Plain Diffie-Hellman authenticates nobody and falls to a party who substitutes their own public key. Key encapsulation mechanisms inherit the property, which is why RFC 9180 places the authenticity of the recipient's public key outside its own scope and assumes the surrounding application establishes it through certificates, a key directory, or out-of-band verification. This model is that surrounding application, and the channel it uses to distribute the recipient key is the component its own trust model labels untrusted.The disclosure anticipates a neighbouring attack and closes it:The claim is write-once/first-wins so a later worker cannot hijack a job's key exchange.— §6, Reference implementationThat reasoning is sound and the mechanism does what it says. It covers one of two symmetric cases.
| Threat | Handled by the write-once claim |
|---|---|
| A second worker overwrites an existing claim | Yes — the write is rejected |
| An unauthorised party writes the claim first | No — the first write wins |
No intermediary (gateway, coordination, storage, monitor) ever holds enough key material to derive either secret. An attacker who compromises coordination or storage obtains only opaque blobs and public keys.— §4.3, Independent per-direction keysThe first sentence is accurate. The second describes an attacker who reads. An attacker who writes places a chosen public key into the claim record before the device polls, and deriving the legitimate secret becomes unnecessary for a party who can arrange to be the counterparty. Whoever governs the contents of that record governs who can read the payload, which makes the coordination layer a trusted component for confidentiality — the one thing §3 says no component besides the device and the worker should ever be.An honest bound on the claim: this does not mean anyone on the open internet can read this data today. In a real deployment the ability to write claims sits behind cloud networking and credentials, and the disclosure describes an authenticating gateway on the device path. The precise problem is that confidentiality now rests on that perimeter, while the architecture's central promise is that it holds without trusting the components between the device and the worker.