Security you can verify, not just trust
Information-theoretic guarantees. Auditable code. NIST-standard primitives. Zero vulnerabilities.
Trust Signals
Verifiable evidence, not marketing claims
| Signal |
Evidence |
| Algorithm |
XorIDA threshold sharing over GF(2) — information-theoretic security, sub-millisecond for typical payloads |
| Test coverage |
4,998+ tests passing, 100% line coverage on crypto module |
| Auditable crypto |
Core XorIDA implementation available for review |
| Patent-pending |
Threshold sharing algorithm with patent protection |
| NIST primitives |
AES-256-GCM, HMAC-SHA256, Ed25519, X25519 via Web Crypto API. Post-quantum: ML-KEM-768 (FIPS 203, deployed), ML-DSA-65 (FIPS 204, deployed, opt-in) |
| Compliance mapping |
HIPAA, SOC 2, GDPR, FedRAMP, CMMC, ISO 27001 |
| Zero vulnerabilities |
npm audit clean, no known CVEs |
Technology Comparison
How XorIDA compares to alternative approaches
| Property |
XorIDA (Ours) |
Shamir's SSS |
FHE |
MPC |
TEE |
| Speed (1MB) |
~33ms |
500ms+ |
Hours |
Seconds |
~1ms |
| Security model |
Info-theoretic |
Info-theoretic |
Computational |
Computational |
Hardware |
| Quantum-proof payload |
Yes (unconditional) |
Theoretically |
Varies |
No |
No |
| Key management |
None required |
Required |
Complex |
Complex |
Hardware-bound |
| Embedded (8-bit) |
Native support |
Impractical |
Impossible |
Impractical |
Requires TEE |
| Operations |
XOR |
Polynomial interp. |
Lattice |
Garbled circuits |
Enclave |
| Share overhead |
1x |
1x |
N/A |
N/A |
N/A |
Security Guarantees
Mathematical invariants, not configuration options
✓
HMAC Before Reconstruct
Every share is verified with HMAC-SHA256 before reconstruction begins. Tampered shares are rejected before the message is ever assembled. This is the single most important security invariant.
∅
No Keys
XorIDA requires no encryption keys, no key exchange, no key rotation, no key escrow. The split IS the security. Nothing to steal, nothing to compromise.
∞
Information-Theoretic
Security is unconditional — not based on the difficulty of factoring large primes or solving discrete logarithms. Even an attacker with infinite computing power cannot reconstruct from fewer than k shares.
↻
Forward Secrecy
Each message uses ephemeral X25519 key agreement. Compromising a long-term key does not reveal past messages. Past sessions remain secure even if future keys are compromised.
“The crypto is textbook correct — Ed25519 for signing, X25519 ECDH for forward-secret key agreement, AES-256-GCM for authenticated encryption, XorIDA threshold sharing with HMAC integrity. Encrypt-then-sign, not the other way around. No homebrew primitives.”
— Vault Engineering Team, after reading the full 1,200-line source
Post-Quantum Readiness
Layered defense — information-theoretic payload + NIST PQ identity
🛡
Quantum-Safe Payload
XorIDA threshold sharing over GF(2) is information-theoretic. Security is unconditional — no computational assumption for a quantum computer to break. The payload layer is quantum-safe today.
🔄
Hybrid PQ Key Exchange — Live
Key establishment uses X25519 + ML-KEM-768 (FIPS 203) hybrid KEM. Session keys derived via HKDF-SHA256 over both shared secrets. Secure as long as either scheme holds. v2 envelopes deployed, backward-compatible with v1 agents. Signatures: Phase 2 deployed — hybrid Ed25519 + ML-DSA-65 (FIPS 204), opt-in via postQuantumSig: true.
⚙
Zero Developer Changes
The PQ upgrade happens in the Xlink infrastructure layer. Agent.create(), agent.send(), and agent.receive() remain identical. All 68 ACIs inherit post-quantum security by updating one dependency.
⏱
Negligible Latency
Hybrid PQ adds ~1.7ms to the full cryptographic handshake (from ~0.4ms to ~2.1ms). Envelope overhead grows by ~6 KB. Both are negligible compared to network I/O latency of 100-500ms per API call.
Phase 1 deployed. The split-channel payload layer is information-theoretic and quantum-safe (XorIDA over GF(2)). Key establishment now uses X25519 + ML-KEM-768 hybrid KEM (FIPS 203) — session keys are secure as long as either scheme holds, protecting against harvest-now-decrypt-later attacks. Signatures remain Ed25519; Phase 2 adds ML-DSA-65 (FIPS 204) for full end-to-end PQ security. See the Xlink white paper §11 for the complete migration plan.
Push-Based Authentication (Xlock)
Asymmetric auth — zero shared secrets on the server
🔓
Asymmetric Auth
Ed25519 challenge-response via the Xlink gateway. The server stores only public keys (DIDs). A server breach exposes zero authentication material — unlike TOTP where shared secrets let attackers generate codes forever.
🚧
Anti-Push-Bombing
Three-layer defense: L1 Xgate rate limiting (max 3 pending per recipient per 5 minutes), L2 challenge-bound Ed25519 signatures (each approval tied to one challenge), L3 context display (app name, IP, countdown timer).
🔄
Single-Use Challenges
Challenge lifecycle: PENDING → APPROVED/DENIED → CONSUMED (or EXPIRED). Consumed challenges cannot be replayed. 5-minute TTL auto-expires stale challenges. UUIDv4 identifiers prevent collision.
⏱
Timing-Safe Verification
All token comparisons use timingSafeEqual() to prevent timing side-channel attacks. Bearer tokens are HMAC-SHA256(did, serverSecret) — deterministic but not guessable. Only the original challenge creator can poll status.
Compliance
Compliance by architecture, not by policy
Healthcare
HIPAA
Protected health information. XorIDA satisfies the encryption requirement under the Security Rule. Split-channel delivery ensures no single provider holds PHI.
Enterprise
SOC 2
Type II compliance. Cryptographic access controls, audit logging, encryption at rest and in transit. Annual audit-ready.
Data Protection
GDPR
Data protection by design. XorIDA enables processing without exposing personal data. Right to erasure via share deletion.
Federal
FedRAMP
Federal risk authorization. NIST 800-53 control mapping. FIPS 140-validated primitives via Web Crypto API.
Defense
CMMC
Cybersecurity Maturity Model Certification. Controlled unclassified information (CUI) protection. Level 2+ readiness.
International
ISO 27001
Information security management. XorIDA addresses Annex A controls for cryptography, communications security, and access control.
Audit
Transparent security posture
✓
npm audit status
Zero known vulnerabilities. npm audit runs in CI and blocks merge on high or critical findings.
✓
Test vectors
Known-answer test vectors for every algorithm, verified against reference implementations.
✓
Fuzz testing
Property-based fuzz tests on the crypto module across all valid (n,k) configurations with statistical independence verification.
✓
Invited audits
Security researchers welcome. Responsible disclosure to security@xail.io.
Responsible disclosure. We invite security researchers to review our cryptographic implementation. If you find a vulnerability, please report it to
security@xail.io. We take every report seriously and will respond within 48 hours.
Ready to evaluate?
Download the technical white paper or schedule a security review with our team.