Hello Wolfram Community,

I wanted to share a project I've been working on that sits at the intersection of
post-quantum cryptography, distributed identity, and applied number theory. I'd be
very interested in feedback from this community, particularly on the mathematical
foundations and the verification strategy.

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 messaging client
whose login is a zero-knowledge proof of vault possession rather than a server-issued
credential.

The two projects together explore a simple thesis: 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:

Eidolon ships post-quantum primitives standardized or under standardization by NIST
PQC, each carrying a distinct role inside the system.

ML-KEM (Kyber1024) is used as the workhorse key-encapsulation mechanism. It targets
NIST security Level 5 with IND-CCA2 security, and serves to derive 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 that
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 treated as 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 the second code-based KEM included, intended as an alternative to Kyber when
an operator wants to lean on conservative parameters. It is selected behind a feature
flag rather than being on the default path.

Schnorr Zero-Knowledge Proofs (NIZK) are implemented over Curve25519 and are how a
vault proves possession to a remote verifier without revealing any of the 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 sitting in a native Rust crate exposed through PyO3 + maturin.
The motivation for Rust is straightforward: timing-side-channel resistance for the
inner loops, plus the ability to ship a single statically-linked artefact across
Windows and Linux without bundling a large Python interpreter alongside the cryptographic state machine.

All of these are wrapped behind a single Python facade (rust_crypto.py) with the
actual implementation in a native Rust crate (PyO3 + maturin). The motivation for
Rust is straightforward: timing-side-channel resistance for the inner loops, plus the
ability to ship a single statically-linked artifact.

1. Holographic key derivation

The cryptographic kernel is what we call a 9-phase holographic key derivation pipeline. Conceptually 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 t₀ cannot be replayed
   at t₁ 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 can be written as

 K_final = Φ₉ ∘ Φ₈ ∘ … ∘ Φ₁ (entropy, material, position, t)

with Φᵢ defined so that the composition is preimage-resistant under standard assumptions on SHA-3 and the underlying lattice problem. A pure-Mathematica reference
implementation of the first three phases (no PQ part) is something I plan to share
if there's interest — it's a nice illustration of how BlockRandom, RandomReal[...,
WorkingPrecision -> ...], and the Cryptography* primitives can be used to build verifiable derivation traces.

1. 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 then 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.

1. 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 in 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.

We've also kept the wire format documented enough that someone could write a Mathematica client against it as a verification exercise — SocketConnect[...], BinarySerialize, and the new Cryptography* package make this surprisingly tractable.

1. Why this matters (and why I'm posting here)

There are three reasons I think a community like Wolfram is the right audience for
early feedback:

1. Verifiable mathematics. The holographic derivation pipeline and the SSS-based
   7-day escrow have a clean algebraic structure that lends itself to symbolic verification. I would love opinions from anyone who has used Mathematica to formally check PQ derivations or threshold schemes — the recent additions to FiniteFields and Permutations look directly applicable.

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. I'd be very interested in a discussion about the right balance between open-source and proprietary cryptographic IP, especially for projects that intend to undergo external audit. The current binary is reproducible-build-friendly (Windows x8664
   and Linux x8664 are published with SHA-256 sums for v1.1.1). 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. Use of math beyond cryptography. Some of the design decisions are informed by
   results from solid-state physics (the "material entropy" mapping leans on optical
   phonon dispersion data), and from differential geometry (the spatial sampling uses
   a stratified sampler on a 7-dimensional manifold). I'd love to know if anyone
   here has tried to use Mathematica's Manifold* primitives for this kind of cryptographically-relevant sampling — there's a real gap in the literature.

4. Concrete artefacts

• Repository: github.com/Oykdo/Eidolon (https://github.com/Oykdo/Eidolon) — current release v1.1.1, signed builds for Windows x8664 and Linux x8664 • Cipher client: github.com/Oykdo/cipher (https://github.com/Oykdo/cipher) — desktop reference implementation • 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 delighted to discuss any of the above — particularly the temporal-prism construction, which I haven't seen treated explicitly in the literature even though
several PQ schemes flirt with the same idea. If anyone here has worked on time-locked
one-way functions, randomness beacons, or formal verification of key-derivation
pipelines, I'd really value the conversation.

Thank you for reading

Best regards,