SchnelPay implements a genuine hybrid ECDSA + ML-DSA-65 authentication system built on audited open-source cryptography. This page documents the full technical specification.
QuantumShield™ Active
Production implementation
Real implementation
Built on @noble/post-quantum — a widely audited, zero-dependency TypeScript PQC library used in production by major crypto projects.
Both signatures required
Every token is signed with both ECDSA and ML-DSA-65. Verification requires both to pass. Fallback to ECDSA-only is logged and flagged.
NIST standard compliant
ML-DSA-65 is the exact algorithm standardised in NIST FIPS 204 (August 2024). Same spec adopted by Google and the US DoD.
Open library provenance
npm: @noble/post-quantum by Paul Miller. Source: github.com/paulmillr/noble-post-quantum. Audited by independent security researchers.
Full documentation of the QuantumShield™ hybrid signature system for independent verification.
Specification 1
Every SchnelPay authentication token uses a dual-signature structure. Both signatures are computed independently over the same payload and stored together in a structured token envelope.
// HybridSignature structure
{
"ecdsa": "<HMAC-SHA256 base64>",
"dilithium": "<ML-DSA-65 signature base64>",
"algorithm": "hybrid-ecdsa-dilithium",
"timestamp": 1234567890123
}
// Full token envelope (base64url encoded)
{
"version": "quantum-safe-v1",
"payload": { "userId": "...", "email": "...", "iat": 0, "exp": 0 },
"signatures": <HybridSignature>
}
Specification 2
Token verification follows a strict hierarchy. Both signatures are verified independently. The result reports which algorithms validated and whether the session is quantum-safe.
Signatures
Both valid
Signatures
Dilithium only
Signatures
ECDSA only
Signatures
Neither valid
* ECDSA-only fallback exists for backward compatibility with legacy tokens. All new tokens require both signatures. ECDSA-only sessions are logged and flagged internally.
Specification 3
ML-DSA-65 (Dilithium3)
ML-DSA-65 was chosen over Dilithium2 (Level 2) for stronger security margins, and over Dilithium5 (Level 5) for performance balance. Level 3 matches AES-192 classical equivalent security.
ECDSA (HMAC-SHA256)
The classical component uses HMAC-SHA256 rather than raw ECDSA secp256k1 to avoid nonce reuse vulnerabilities. The 64-byte key is generated using cryptographically secure randomness.
Specification 4
SchnelPay uses @noble/post-quantum by Paul Miller for ML-DSA-65. This library is widely regarded as one of the most trustworthy PQC implementations available in any language.
npm package
@noble/post-quantum
Author
Paul Miller (paulmillr)
Language
TypeScript — zero dependencies
Algorithm used
ml_dsa65 (FIPS 204)
License
MIT
Audit status
Independently audited
// Import used in production
import { ml_dsa65 } from '@noble/post-quantum/ml-dsa.js';
// Key generation
const keys = ml_dsa65.keygen();
// Returns: { publicKey: Uint8Array, secretKey: Uint8Array }
// Signing
const sig = ml_dsa65.sign(message, secretKey);
// Verification
const valid = ml_dsa65.verify(sig, message, publicKey);
Specification 5
Dilithium key pairs are generated once and stored as environment variables on the server. Keys are never exposed to clients, never logged, and never stored in the database.
Key generation
ML-DSA-65 key pair generated server-side using @noble/post-quantum keygen(). Produces publicKey and secretKey as Uint8Array.
Key storage
Keys stored as Base64-encoded environment variables (DILITHIUM_PRIVATE_KEY, DILITHIUM_PUBLIC_KEY) in Railway secure vault. Never in code or database.
Key loading
On server startup, keys are loaded from environment into memory as a singleton instance. If missing, new keys are generated and logged for manual storage.
Signing
Each authentication token is signed using the in-memory secret key. The signature is stored in the token envelope, not on the server.
Verification
Tokens are verified using the public key only. The secret key is never used during verification. Public key rotation invalidates all existing tokens.
QuantumShield™ is one layer of a multi-layered security architecture.
Every session token is signed with both ML-DSA-65 and HMAC-SHA256. Tokens expire after 7 days and cannot be forged without the server secret key.
Automatic lockout after repeated failed login attempts. Redis-based rate limiting per endpoint. Cryptographically secure TOTP for 2FA.
bcrypt password hashing with 12 rounds. 10KB payload limits. Strict CORS policy. HTTPS enforced. No sensitive data in logs.
Deployed on Railway with encrypted environment variables. Cloudflare CDN with DDoS protection. PostgreSQL with parameterised queries throughout.
Security researchers and technical users are welcome to reach out with questions about the QuantumShield™ implementation.