Independently verify the open Blind CLI and reproduce the public replication checks that are currently runnable from the CLI-only repository.
3 files
These are agent-executable recipes — step-by-step instructions written primarily for AI agents (MCP-style tool use), not humans. Each skill tells an agent exactly how to do one job with The Blind Machine using only open tools and public data.
Installable recipes — a SKILL.md plus its
references/, packaged as a small repository your agent
downloads and runs.
How agents use this
Download and install one into your agent's skills directory in a single command (it unpacks as a ready-to-use folder):
curl -fsSL https://blindmachine.org/skills/replicate/archive | tar xz -C ~/.claude/skills
Or fetch just the recipe to execute inline:
curl https://blindmachine.org/skills/replicate.md
Independently verify the open Blind CLI and reproduce the public replication checks that are currently runnable from the CLI-only repository.
3 files
Independently review The Blind Machine paper the way a careful, skeptical referee would — verifying every claim against evidence rather than accepting it.
3 files
Copy-paste instructions to drop straight into your own AI agent (Claude Code, Claude, ChatGPT, …) — no install needed. Each is self-contained: it names the exact sources to read. Expand one to see the full prompt, or just hit Copy prompt.
Does the open-source code actually enforce what the paper promises?
You are a security researcher. Independently audit the open-source `blind` CLI and decide whether its real behavior backs the security and trust claims in The Blind Machine paper.
1. Download the canonical paper PDF from https://github.com/blindmachine/paper, then read every page:
curl -fL https://raw.githubusercontent.com/blindmachine/paper/main/paper.pdf -o paper.pdf
Use a PDF-capable reader, or run `pdftotext paper.pdf paper.txt` and read the complete text.
2. Clone and read the CLI: https://github.com/blindmachine/blind
3. For each security-relevant claim — the open/auditable trust surface (Kerckhoffs), fail-closed signature verification, ciphertext-only upload, secret keys never leaving the client, the signed-invitation URL-fragment trust anchor (`#k=`), and content-addressed/deterministic bundles — find the code that is supposed to enforce it and judge whether it actually does.
4. Try to break each guarantee: what could a malicious server, a forged or unsigned invitation, a tampered bundle, or a stripped signature achieve? Confirm the CLI fails closed rather than warning-and-continuing.
Return a severity-ranked list of findings. For each: the claim, the file/function that implements it (quote line references), whether the code supports the claim, and any gap between the prose and the behavior. Mark anything you could not verify as "unverified" and say why.
A skeptical, evidence-first referee report — six dimensions, one fix per finding.
You are a skeptical peer reviewer writing an independent referee report on The Blind Machine paper. Your job is to find problems, not to praise. First download and read the canonical PDF from https://github.com/blindmachine/paper: curl -fL https://raw.githubusercontent.com/blindmachine/paper/main/paper.pdf -o paper.pdf Read every page with a PDF-capable reader, or extract it with `pdftotext paper.pdf paper.txt` and read the complete text. Do not substitute a hosted Markdown draft. Install the repository's own review recipe and follow it exactly: curl -fsSL https://blindmachine.org/skills/review/archive | tar xz -C ~/.claude/skills It walks six dimensions — claim-evidence integrity, the per-attack security catalog, honesty/overclaiming, citation integrity, reproducibility, and scope — and checks every headline number against its committed source. Verify claims against evidence rather than accepting the prose; prefer one specific, reproducible finding over a general impression. Return a severity-ranked review with a concrete fix per finding, and state explicitly which dimensions are clean.
Re-run the CLI trust loop and the paper's E1-E10 from the public materials.
You are a researcher reproducing a paper's results. Independently replicate The Blind Machine end to end and report what holds up. Install the replicate recipe and follow it: curl -fsSL https://blindmachine.org/skills/replicate/archive | tar xz -C ~/.claude/skills First download and read every page of the canonical paper PDF from https://github.com/blindmachine/paper: curl -fL https://raw.githubusercontent.com/blindmachine/paper/main/paper.pdf -o paper.pdf Then: verify the open `blind` CLI (https://github.com/blindmachine/blind) — download a signed application bundle from the public registry, verify its digest and Ed25519 signature, seal the environment, and run the deterministic encrypted simulation plus the K-vs-K+1 differencing demo. For the full paper replication, use the separate replication-materials repository at github.com/blindmachine/the-blind-machine-paper, verify its `MANIFEST.sha256`, then run `experiments/run_all.sh` + `experiments/verify.py` (and the E5-E10 scripts, which cover the public-genome studies plus the HEPRS and GWAS reproductions). End with a PASS / FAIL / SKIP line per check; SKIP only for a genuinely missing prerequisite (no network or toolchain).
What is guaranteed, what must be trusted, and when a different tool fits better.
You are evaluating whether to trust The Blind Machine with sensitive data. Give me a clear-eyed threat model, not marketing. Download the canonical paper PDF from https://github.com/blindmachine/paper and read every page, then skim the open CLI (https://github.com/blindmachine/blind): curl -fL https://raw.githubusercontent.com/blindmachine/paper/main/paper.pdf -o paper.pdf Use a PDF-capable reader, or run `pdftotext paper.pdf paper.txt` and read the complete text. Do not substitute a hosted Markdown draft. Answer plainly, citing the paper section or CLI file behind each point: - What exactly stays confidential, and from whom — the server operator, other contributors, a network attacker? - What must I trust, and what is verifiable without trust? Where is the trusted computing base? - What does the server learn or control, including the final aggregate value? - What are the failure modes and the explicit non-goals or deferred items (e.g. verify-by-re-execution)? - When is this the right tool, and when is plain FHE, MPC, or a trusted enclave a better fit? Flag anything that reads as overclaimed.