Assets we protect
The main protected assets are:
- the complete encrypted wallet;
- the recovered password candidate;
- private keys and transaction-signing authority;
- customer identity and contact information;
- the integrity of search assignments and operator credit;
- settlement destinations and amounts.
The design starts from the assumption that an operator machine may be curious or malicious and that the coordinator may be compromised.
Trust zones
| Zone | Trust level | Responsibilities |
|---|---|---|
| Owner environment | Owner-controlled | Holds the full wallet in non-custodial recovery and performs final local wallet operations |
| Secure intake and high-trust authoring | High trust | Accepts allowed case material, derives extracts, and signs authorized work |
| Coordinator | Semi-trusted | Schedules leases and relays signed work and sealed results |
| Operator device | Untrusted | Tests assigned passwords against a safe test piece |
| Verify | High trust | Opens candidate reports and performs authoritative wallet checks |
| Recovery and settlement workflow | High trust | Uses the verified result to complete the authorized recovery |
A boundary is useful only if the data crossing it is constrained. The coordinator does not become safe merely because it is called semi-trusted; it is kept away from the full wallet and plaintext candidate by protocol design.
Controls at each boundary
Intake sealing
For direct uploads, supported case material is sealed before storage using an ephemeral X25519 key agreement, HKDF-SHA-256, and ChaCha20-Poly1305. Authenticated context is included as associated data. The public intake surface does not hold the private key needed to unseal the ciphertext.
When a Blockchain.com case begins with an identifier and requires server-side retrieval of the encrypted backup, that retrieval path cannot be described as browser-side file encryption. The retrieved encrypted wallet is sealed in the controlled intake path and removed from transient handling as soon as practical.
Signed authorization
Ed25519 signatures protect the case manifest, search chunks, and approved tool catalog. Signed content binds the wallet type, custody mode, safe-test-piece hash, search definition, and tool artifact. An agent fails closed when those values or signatures do not agree.
Operator devices also authenticate their lease and report requests. This supports attribution and prevents an arbitrary unauthenticated client from claiming work.
Candidate sealing
A possible password is encrypted to Verify with an ephemeral X25519 exchange, HKDF-SHA-256, and ChaCha20-Poly1305. The lease and assignment context is authenticated with the ciphertext. The coordinator can store and relay the report but cannot open it.
Sealing protects the network and coordinator path. It cannot prevent the owner of an untrusted operator machine from inspecting a password found on that same machine.
Independent verification
Verify rechecks signatures, extract identity, and assignment membership before wallet validation. It does not accept the search tool’s result as ground truth. The final wallet check is specific to the format, as described for Blockchain.com and Bitcoin Core.
What a compromised component can do
| Compromised component | Possible impact | Primary constraint |
|---|---|---|
| Coordinator | Delay, omit, replay, or mis-schedule work | Cannot forge signed work or decrypt sealed candidates |
| Operator device | Inspect its extract, chunk, and locally tested candidates; lie about progress | Has no full wallet or spendable key records; results require verification |
| Public website | Mislead or collect form data | Direct wallet material belongs only in the separate secure intake path |
| Owner computer | Observe password, wallet plaintext, keys, or signing | No software-only process can prove a general-purpose host is clean |
| High-trust Verify or recovery workflow | Access a recovered candidate and allowed wallet evidence | Organizational and operational controls remain necessary |
The last row is why the service is trust-minimized rather than trustless.
Current limitations
- The operator agent uses separate supervisor and runner processes, but the current implementation does not yet provide a strong, separate OS sandbox between them.
- Non-custodial recovery reduces wallet custody but still depends on the security of the owner’s computer and the guided procedure.
- Recovery Room—including its proposed reproducible desktop releases—and hardware-enclave verification are planned. Transparency-log code exists, but no public production log is active.
- Custodial recovery requires trust in Distribrute’s high-trust handling and settlement process.
- A malicious original wallet file may exploit a parser despite defensive validation; accepted formats are therefore narrowly scoped and reviewed.
- Cryptography cannot make an incorrect payout address or an infected customer host safe. Human review remains part of the ceremony.
Security claims we do not make
Distribrute does not claim that:
- the service is completely trustless;
- operators cannot observe a password found on their own hardware;
- a non-custodial customer computer is automatically safe;
- every compatible wallet can be recovered;
- missing seed phrases or private keys can be reconstructed—see What we cannot recover;
- planned transparency or isolation features protect current cases before they are deployed.
Current availability is tracked separately in Implementation status. The exact data given to operators is documented in Safe test pieces.