 |
Today at 06:28:38 AM |
|
Hello BitcoinTalk,
I wanted to share a project that intersects post-quantum cryptography,
self-sovereign identity, and practical key management. I'd appreciate
feedback from this community, particularly on the trust model and the
economic design.
Abstract
Eidolon is a local-first cryptographic vault system designed to remain
secure against quantum adversaries. It produces, stores, and
authenticates cryptographic identities without ever delegating trust to a
remote service. Cipher is the first application that uses Eidolon as its
root of trust: an end-to-end encrypted messenger whose login is a
zero-knowledge proof of vault possession rather than a server-issued
credential.
The thesis is straightforward: if your private keys never leave your
machine and the underlying mathematics resist Shor's and Grover's
algorithms, then a useful subset of "social" software (messaging,
signing, presence) can be rebuilt without trusted third parties.
1. Cryptographic primitives
Eidolon ships post-quantum primitives standardized or under
standardization by NIST PQC, each carrying a distinct role inside the
system.
ML-KEM (Kyber1024) is the workhorse key-encapsulation mechanism. It
targets NIST security Level 5 with IND-CCA2 security, and derives
ephemeral session keys for a hybrid TLS-like channel between vaults and
any remote verifier.
ML-DSA (Dilithium5) provides lattice-based digital signatures. It is the
canonical signing primitive for vault attestation and ownership-transfer
messages, so every state-changing operation against the lock server
carries a Dilithium signature the server can verify without ever seeing
the private material.
Classic McEliece is bundled as a code-based KEM whose security assumption
is independent from lattice problems. It is a long-term resistance
backup: if a future cryptanalytic advance weakens lattice schemes faster
than the threat model anticipates, the McEliece path keeps the protocol
usable until a migration is performed.
HQC is a second code-based KEM, selected behind a feature flag as an
alternative to Kyber for operators who prefer conservative parameters.
Schnorr Zero-Knowledge Proofs (NIZK) over Curve25519 are how a vault
proves possession to a remote verifier without revealing any underlying
private material. The proof is what the Eidolon Connect bridge transmits
when a mobile device authenticates against a desktop vault.
All of these are wrapped behind a single Python facade (rust_crypto.py)
with the actual implementations in a native Rust crate (PyO3 + maturin).
The motivation for Rust: timing-side-channel resistance for the inner
loops, plus a single statically-linked artifact across Windows and Linux
without bundling a large Python interpreter alongside the cryptographic
state machine.
2. Holographic key derivation
The cryptographic kernel is what we call a 9-phase holographic key
derivation pipeline. It generalizes PBKDF2/Argon2 along three orthogonal
dimensions:
1. Material entropy — a real-world physical material descriptor (256
catalogued materials, each with measured optical and elastic
properties) seeds a parameterized phase function.
2. Spatial entropy — coordinates drawn from a deterministic sampling of
an internal manifold provide a second axis of variation.
3. Temporal entropy (EEP-001 prism) — a "temporal prism" masks the
derivation by time-shifting intermediate state, so an output produced
at t0 cannot be replayed at t1 without re-running the pipeline with
the original temporal seed. This is what makes the dual-key format
(.psnx + .blend_data) non-clonable in isolation.
Each phase composes a keyed permutation on a 4096-bit working buffer. The
full pipeline:
K_final = Phi9 . Phi8 . ... . Phi1 (entropy, material, position, t)
with Phi_i defined so that the composition is preimage-resistant under
standard assumptions on SHA-3 and the underlying lattice problem.
3. Identity layer
A vault is identified by two files that must be present together to
authenticate:
• A .psnx file (~17 KB) containing the public material, the post-quantum
public keys, an authenticated metadata block, and a Schnorr
commitment.
• A .blend_data file (~156 KB) containing the temporally-masked private
material. This file is useless without both the corresponding .psnx
AND the original temporal context.
Neither file alone allows unlock. This is enforced cryptographically (the
AEAD tag in the .blend_data depends on values published only in the
.psnx), not just by convention. Vaults are bound to a specific machine
through a per-host hash (machine_lock) that prevents trivial file-copy
attacks.
For cross-device flows (e.g. logging into Cipher on a phone), Eidolon
exposes a short-lived session bridge based on a NIZK Schnorr proof
transmitted over QR. The verifier only learns "this prover holds a
private key matching this public key" — never the key itself.
4. Cipher: a first client of the protocol
Cipher is a desktop messenger (React 19 / Electron / Fastify backend /
PostgreSQL) that uses an Eidolon vault as the only credential. It
implements:
• X3DH for asynchronous key agreement
• Double Ratchet for forward-secret per-message keys
• libsodium for the symmetric inner layer
Mathematically it's the standard Signal construction. Where Cipher
diverges is the trust root: the long-term identity key of a Cipher user
is not issued by Cipher's server; it is derived from the user's Eidolon
vault. The Cipher backend never sees the private material, never can
compel its disclosure, and never can impersonate a user even with full
database access.
Server-side message retention is user-configurable (0-30 days
post-pickup). Zero-retention means messages are burned from the server
the instant all recipients have picked them up. No plaintext ever
persists.
5. Why this matters (and why I'm posting here)
Three reasons I think the BitcoinTalk community is the right audience:
1. Self-sovereign identity without chains. Eidolon is a local vault — no
blockchain, no token, no consensus. The identity is anchored in
post-quantum key material that never leaves the user's device. If
you've followed the DID/SSI space, this is a different bet: trust
comes from possession of a mathematical object, not from an on-chain
registration or a federation of signers. I'd value opinions from
anyone who has explored non-chain identity models.
2. Open primitives, closed pipeline. The repo at github.com/Oykdo/Eidolon
ships the public surface (SDK, daemon CLI, integration tests, build
tooling); the proprietary derivation kernel ships as a signed native
binary. The current binary is reproducible-build-friendly (Windows
x86_64 and Linux x86_64 are published with SHA-256 sums for v1.1.1).
I'd be interested in discussion about the right balance between
open-source and proprietary cryptographic IP, especially for projects
that intend to undergo external audit.
Cipher and Eidolon downloads are not yet code-signed, so Windows shows a
SmartScreen warning. Click "More info" then "Run anyway" — it's a
heuristic check, not a malware detection.
3. Time-locked constructions. The temporal prism in the derivation
pipeline shares DNA with the time-lock puzzle literature (Ribes-Wong,
Blockstream's op_csv, drand networks). If anyone here has worked on
time-locked one-way functions, randomness beacons, or hash-based delay
commitments, I'd really value the conversation — I haven't seen the
temporal-masking construction treated explicitly in the literature
even though several PQ schemes flirt with the same idea.
6. Concrete artefacts
• Repository: github.com/Oykdo/Eidolon — current release v1.1.1, builds
for Windows x86_64 and Linux x86_64
• Cipher client: github.com/Oykdo/cipher — desktop reference
implementation, current release v1.3.4
• License: proprietary commercial (Logos Project) for the kernel; public
scaffolding is auditable
• Active priority: a formal write-up of the EEP-001 temporal prism with
security proofs in the random-oracle model
I'd be happy to discuss any of the above — particularly the
temporal-prism construction and the no-chain identity model. If you've
thought about what "be your own bank" looks like when the adversary has a
quantum computer, this is that conversation.
Thank you for reading
|
