Assets we protect
The main protected assets are:
- the complete encrypted wallet;
- the recovered password candidate after it leaves the operator host;
- 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 |
| Customer wallet extractor | Owner-controlled | Reads the wallet locally and emits the safe extract; its opt-in Blockchain.com build contacts only blockchain.info |
| 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 and can inspect all candidates handled locally |
| 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
Customer-side extraction
The offline extractor CLI and GUI contain no networking dependency and no automatic submission code. The owner selects a wallet file, derives the safe extract locally, and deliberately transfers that result into the accepted-case workflow. Release gates inspect the offline CLI dependency graph, observe a representative extraction for network system calls, and require malformed, empty, and oversized inputs to fail cleanly.
Blockchain.com GUID retrieval is deliberately a separate build. With its net feature enabled, it
can contact only https://blockchain.info/, follows no redirects, and uses generic network errors so
the GUID and session bearer token are not logged. That boundary keeps the encrypted backup away from
Distribrute, but it necessarily discloses the request to Blockchain.com and places the retrieved
encrypted payload in the owner’s process memory.
These controls are properties of the reviewed source and build. A substituted binary running on the owner’s computer could read or transmit the wallet, and an offline process can still expose data to local malware, swap, crash dumps, or a vulnerable parser. Build provenance and reproducibility evidence reduce software-distribution trust; they do not prove the host is clean.
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.
The work package omits the full wallet, direct identity and contact fields, complete address list,
balance, and transaction history. That does not make the password itself anonymous: a password or
candidate list can contain names, dates, reused credentials, or other personal information. Safe
pieces can also expose narrowly bounded format metadata. In particular, an older Electrum BIE1
piece may reveal a prefix of the first wallet address, while a MultiBit Classic .key piece reveals
a bounded, non-spendable WIF prefix after a correct candidate is tested.
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, Bitcoin Core, Electrum, and MultiBit.
What a compromised component can do
| Compromised component | Possible impact | Primary constraint |
|---|---|---|
| Customer extractor or substituted build | Read, alter, or exfiltrate the owner’s wallet before the safe piece exists | The reviewed offline implementation has no network or automatic submission path; owners must verify the build and host |
| 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—including a correct password; 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; prevent non-custodial settlement from completing | No software-only process can prove a general-purpose host is clean or force its owner to authorize settlement |
| 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.
- The extractor zeroizes its outer in-memory wallet buffer, but wallet-engine parser copies, SQLite allocations, the online Blockchain.com payload, operating-system swap, and crash dumps are not all guaranteed to be scrubbed.
- 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.
- Many wallet formats do not reveal usable public addresses before decryption. Their spendable balance may be unverifiable before compute begins, and a correct password may open an empty wallet.
- 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;
- password candidates cannot contain identifying or reused information;
- a non-custodial customer computer is automatically safe;
- an “offline” label proves that a substituted binary or the surrounding operating system is safe;
- every compatible wallet can be recovered;
- a correct password proves that the wallet is funded or guarantees an operator payout;
- 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 created by the Customer wallet extractor and given to operators is documented in Safe test pieces, and payment conditions are documented in Operator rewards and settlement.