Appreciate the pushback — you're right on every point, and this is
exactly the kind of review the project needs.
On "boring failures eat first": Agreed. Bad entropy, swap, crash dumps,
clipboard, Windows indexing — these kill you before any quantum adversary
shows up. We've now published an explicit threat model
(
https://github.com/Oykdo/Eidolon/blob/main/docs/THREAT_MODEL.md) that
lists endpoint compromise, OS-level data leakage, and user operational
errors as out of scope — not because they don't matter, but because we're
honest about what a local-first desktop vault can and cannot protect
against. No local-first system survives a fully compromised endpoint.
We'd rather say that upfront than pretend otherwise.
On "server cannot decrypt" / "plaintext never persists": These are
architectural claims, not proven guarantees. The server never receives
private keys or plaintext — that's a protocol property we can verify. But
"never persists in any form anywhere on the device" is a much stronger
claim that depends on the OS, and we don't make it unconditionally. Crash
dumps, swap, and hibernation files are real attack surfaces. We're
working on mlock and disabling core dumps, but that's defense-in-depth,
not a proof.
On what you asked for — we've published:
• Formal spec
(
https://github.com/Oykdo/Eidolon/blob/main/docs/FORMAL_SPEC.md) for
the 9-phase derivation pipeline: inputs, outputs, security guarantees
per phase, composition security claim, and explicit admission that
phases 2–6 add structural complexity but zero additional entropy
beyond the master seed.
• Threat model
(
https://github.com/Oykdo/Eidolon/blob/main/docs/THREAT_MODEL.md):
assets, in-scope/out-of-scope adversaries, cryptographic assumptions,
specific risks (dual-file requirement, temporal masking fragility,
machine lock migration, entropy source quality).
• Test vectors
(
https://github.com/Oykdo/Eidolon/blob/main/docs/TEST_VECTORS.json):
deterministic input→output pairs from the Rust binary (AES-GCM,
Shamir, ZKP scalar, full pipeline). You can verify any conforming
implementation against these without seeing the source.
• Reproducible build plan (
https://github.com/Oykdo/Eidolon/blob/main/do cs/REPRODUCIBLE_BUILDS.md): pinned deps, deterministic PyInstaller,
GPG-signed releases, Azure Trusted Signing for Windows. Not fully
implemented yet — the plan is there, the execution is in progress.
On composition being the dangerous bit: This is the sharpest point and
the one we take most seriously. The formal spec makes the composition
claim explicit: if SHA3-512 is preimage-resistant and ML-KEM/ML-DSA are
secure at their claimed levels, then the vault key is computationally
infeasible to recover without the seed. The custom phases (2–6) are a
hash chain under SHA3-512 — they add structural complexity but the
security reduction goes through the standard assumptions. We're not
claiming the custom phases are a new hardness assumption.
On external review: We want it. The primitives (Kyber, Dilithium) have
NIST review. The composition is where external eyes matter most. If you
or anyone here wants to review the formal spec and test vectors, we'll
engage seriously.
The honest summary: this is a local-first vault with post-quantum key
exchange and a structured derivation pipeline. It's not a proof of
security. The documents above are our way of saying: here's what we
claim, here's what we don't, here's how to check us. Footgun with good
branding is exactly what we're trying to avoid.
