Trust Architecture
Post-Quantum Document Sovereignty & Immutable Integrity Verification
Executive Digital Notary (EDN) is not a notary service. It is cryptographic infrastructure. We apply NIST-standardized Post-Quantum Cryptography (PQC) and stateless blockchain anchoring to produce an immutable, verify-anywhere record of truth that outlasts current and future computational limits.
View Architecture DiagramThe Quantum Threat to Legal Infrastructure
Traditional digital signatures rely on RSA-2048 and ECDSA algorithms. Both are mathematically vulnerable to Shor's Algorithm, executable on a sufficiently advanced quantum computer. The "Harvest Now, Decrypt Later" (HNDL) attack vector means adversaries are archiving encrypted legal documents today, with the intent to break them within the next 10–15 years.
A deed notarized in 2025 with RSA-based signatures may be cryptographically unverifiable by 2035. EDN was engineered to prevent this failure mode before it occurs.
| Signature Algorithm | RSA-2048 / ECDSA |
|---|---|
| Key Storage | Software-based |
| Integrity Horizon | ~10 years |
| Quantum-Resistant | No |
| Data Persistence | Provider database (indefinite) |
| HNDL Vulnerability | Yes |
| Signature Algorithm | SPHINCS+ (SLH-DSA) — NIST FIPS 205 |
|---|---|
| Key Storage | FIPS 140-2 Level 3 Hardware HSM |
| Integrity Horizon | 50+ years (mathematical) |
| Quantum-Resistant | Yes |
| Data Persistence | 24-hour PII purge (MHMDA compliant) |
| HNDL Vulnerability | Mitigated |
Infrastructure: The EDN Sovereign Silo
EDN does not commingle client data. Every session operates in an isolated security silo enforced by Google Cloud VPC Service Controls.
Architecture subject to ongoing security review. GCP infrastructure powered by Google Cloud HSM and Blockchain Node Engine.
Post-Quantum Cryptographic Layer: SPHINCS+ (SLH-DSA)
Every document processed through EDN receives a Secondary Post-Quantum Wrapper using the SPHINCS+ algorithm, standardized by NIST as FIPS 205 (SLH-DSA).
Unlike lattice-based PQC methods, SPHINCS+ requires no state management. This makes it the most robust and failure-resistant algorithm for long-term legal document integrity. There is no "state corruption" failure mode.
Every SPHINCS+ signing key is generated inside and never leaves a Google Cloud Hardware Security Module (FIPS 140-2 Level 3). Keys are never extractable in plaintext under any operational condition.
The security of a SPHINCS+ signature rests entirely on the collision-resistance of the underlying hash function (SHA-256 / SHAKE-256). It does not depend on the hardness of integer factorization or elliptic curve discrete logarithms — the two problems quantum computers will first break.
The final SPHINCS+-signed hash of every EDN document is anchored to the Ethereum Mainnet via a dedicated node maintained on GCP Blockchain Node Engine, providing 99.9% anchoring availability and full auditability without reliance on third-party RPC providers.
Compliance Architecture
EDN is designed to align with SOC 2 Type 2 Processing Integrity standards and Washington MHMDA compliance. Authorized Sub-Processors include: Google Cloud Platform (HSM, Blockchain Node Engine, VPC), Paubox (encrypted communications), Stripe (payment processing), Neon (database infrastructure), and PROOF/Notarize.com (RON session platform).
EDN utilizes public blockchain networks strictly as a neutral, non-custodial decentralized timestamping mechanism. The platform anchors document cryptographic hashes to achieve independent tamper-evidence; EDN does not facilitate, custody, or manage digital financial assets, tokens, or smart-contract-based securities.
Developer Platform — Coming Soon
EDN is building a developer-first API layer that will allow title companies, FinTech platforms, DAOs, and legal tech integrators to programmatically submit documents for PQC-secured notarization and blockchain anchoring.
The EDN Platform API will provide endpoints for:
- Secure document submission and hash generation
- SPHINCS+ signature verification
- Blockchain anchor lookup and certificate retrieval
- Biometric-gated session initiation (OAuth 2.0 / PKCE)
- Webhook callbacks for session completion and audit events
