Every security claim we make is mathematically provable. Here's how to verify each one yourself.
Open your browser's Network tab (F12 > Network) before storing a key. You'll see:
// What your browser sends to our server: POST /api/v1/keys/store { "share1": "AXZ3djsE48Nt...", // Half the key (Shamir share) "vaultCommitment": "a3f8..." // Hash commitment } // What is NOT in the request: // Your actual API key. It doesn't appear anywhere in the network traffic. // The other half (Share 2) stays in your browser's localStorage.
How to verify: Open DevTools > Network tab > store a key > inspect the POST request body. The API key itself is nowhere in the payload.
Even if someone breaches our database, they get encrypted garbage:
// What's stored in our database: share1_encrypted: 0xa8f3b2c1... // AES-256-GCM encrypted // (salt + IV + auth tag + ciphertext) // What an attacker gets from a DB breach: // Encrypted blob. Useless without VAULT_ENCRYPTION_KEY (not in DB). // AND useless without Share 2 (not on our server at all).
How to verify: Our encryption uses AES-256-GCM with random salt and IV per encryption. Same plaintext produces different ciphertext every time. Tampered data is detected by the GCM auth tag. We have 14 security tests proving this.
Try it yourself — send a fake ZK proof to the proxy endpoint:
curl https://api.vaultproof.dev/api/v1/proxy/call \
-H "Content-Type: application/json" \
-d '{
"keySlotId": "any-uuid",
"share2": "fake-share",
"zkProof": "this-is-a-fake-proof",
"nullifier": "fake-null",
"appId": "test",
"targetPath": "/v1/models",
"method": "GET"
}'
// Response:
{ "error": "Invalid ZK proof", "reason": "Proof verification failed" }
How to verify: Run the curl command above. The server uses Barretenberg to verify every proof against the Noir circuit. No valid proof = no key reconstruction.
Every proxy call requires a unique nullifier. Reusing one is immediately caught:
// First request with nullifier "abc123": 200 OK — Call goes through // Second request with same nullifier "abc123": 403 Forbidden — "Proof already used (replay detected)"
How to verify: Make two proxy calls with the same nullifier. The second one is rejected. Nullifiers are stored in a database with a unique constraint — duplicates are impossible.
All requests must go through our Cloudflare edge proxy with HMAC signatures. Direct access returns 403:
// Through edge proxy (HMAC signed): curl https://api.vaultproof.dev/health {"status":"ok","service":"vaultproof-edge","secured":true} // Direct to backend (no signature): curl https://[backend-url]/api/v1/keys/list {"error":"Forbidden"}
How to verify: Every request is HMAC-SHA256 signed with a 30-second timestamp. Expired or forged signatures are rejected. The shared secret never travels over the wire.
Our Noir circuit is 70 lines. Here's exactly what it proves:
// key_auth.nr — The entire ZK circuit fn main( // Private (you know these, server doesn't) slot_secret: Field, // Your device secret share_hash: Field, // Hash of your Share 2 app_auth_path: [Field; 10], // Merkle proof of app nonce: Field, // Fresh random value // Public (server verifies these) vault_commitment: pub Field, // Proves you own the key app_id_hash: pub Field, // Proves app is authorized nullifier: pub Field // Prevents replay ) { // 1. Prove ownership assert(poseidon(slot_secret, share_hash) == vault_commitment); // 2. Prove app is authorized (Merkle membership) assert(verify_merkle_path(app_id_hash, ...)); // 3. Prove freshness (anti-replay) assert(poseidon(slot_secret, nonce) == nullifier); }
How to verify: Read the full circuit source on GitHub. Compile it yourself with nargo compile. Run the 4 built-in tests with nargo test. The math is the proof.
How to verify: Clone the repo. Run npm test. All 40 tests are deterministic and reproducible.
Not just policy-prohibited. Mathematically proven.