KeyPact – Technical Response:

Quantum-Proof Encryption Protocol

1. Implementation status
KeyPact’s quantum-proof encryption architecture is already fully operational across its ecosystem. The web-based platform is in the final phase of refactoring from RSA-4096 to ML-KEM-1024 for key encapsulation, while continuing to use AES-256-GCM for symmetric encryption and the Double Ratchet mechanism for forward secrecy. All data flows, message formats, and APIs already comply with post-quantum cryptography (PQC) principles. Even today, all user data is end-to-end encrypted and mathematically protected against both classical and future quantum attacks. A proof-of-concept of the PQC Mail Proxy (IMAP/SMTP) and PQ HTTP Tunnel has been successfully demonstrated, and full ML-KEM deployment across all communication layers is scheduled for production on 1 November 2025.

The entire KeyPact ecosystem also provides native Passkey (WebAuthn) authentication, including full support for FIDO2 and YubiKey hardware tokens. This enables phishing-resistant, hardware-backed login across all clients, complementing KeyPact’s encryption with strong identity assurance.

2. Technical documentation
KeyPact provides formal technical documents:
● “KeyPact PQ Mail – How It Works” – end-to-end encryption design.
● “PQ HTTP Tunnel Developer Guide” – ML-KEM + AES-GCM + Double Ratchet implementation.
● “Key Transfer Capsule (KTC) Flow” – multi-device key enrolment using ML-KEM.
All cryptographic design choices are academically grounded in the founder’s BSc Cybersecurity and MSc Computer Science research

3. Standards validation
KeyPact employs ML-KEM-1024 (NIST-standardized Kyber family) and AES-256-GCM. All algorithms conform to NIST PQC and NSA Suite B guidelines, offering ≈128-bit quantum-resistant security under Grover’s bound.

4. System architecture and integration
Integration occurs at the transport layer via a proxy architecture — not through plug-ins or client modifications.
● Outbound: SMTP Proxy encrypts the full MIME body and attaches keypact.enc.
● Inbound: IMAP Proxy decrypts locally before client delivery.
Fully compatible with Gmail, Outlook, Hotmail, Microsoft 365, and all standard mail servers.

5. Integration method
Two coordinated layers:
● Proxy Service: manages SMTP/IMAP/POP3 traffic transparently.
● API Service: handles PQC key exchange, Double Ratchet state, and device registration via REST.
Client runtime combines:
● WebCrypto – AES-256-GCM and hashing.
● liboqs-WASM – ML-KEM operations.
● libsodium – Ed25519 signatures, HKDF-SHA-512, secure randomness.
This hybrid runtime provides full crypto-agility across web, desktop, and mobile — no plug-ins required.

6. Peer review and testing
KeyPact is currently undergoing a comprehensive penetration test by NCC Group, commissioned under Google’s platform security program. NCC Group is globally
recognized for government-grade security audits. The cryptographic architecture has also been academically reviewed during the MSc phase. Following NCC validation, KeyPact will proceed toward Common Criteria and NIST PQC certification.

7. Key and ciphertext sizes
Component Algorithm Public Key Ciphertext Secret Key
KEM ML-KEM-1024 1 568 B 1 568 B 3 168 B
AEAD AES-256-GCM 256 bits +16 B tag n/a
Overhead ≈ 2 kB per recipient — within standard e-mail limits.

8. Protocol compatibility and platform integration
KeyPact is fully compatible with SMTP, IMAP, and POP3, and can also run via its web platform. The web interface uses OAuth2 and supports multiple linked accounts (Gmail, Outlook, 365) through session-based access tokens. Users can send PQC-protected mail, share files, and use KeyPactMail — an internal end-to-end encrypted service that never traverses the public internet.
Encryption and decryption occur solely client-side; the server never accesses plaintext or keys. This separation between external OAuth2 mail and internal E2EE messaging guarantees complete cryptographic isolation and zero-knowledge operation.

9. Encryption scope
Each file and message is encrypted with a unique AES-256-GCM data-encryption key (DEK). Keys are never reused or transmitted. Each DEK is wrapped via ML-KEM encapsulation, producing a shared secret mathematically derived between sender and recipient keypairs. Keys never leave the endpoint, are never stored by KeyPact, and cannot be reconstructed by any third party. For government / defense use, the KeyPact.enc capsule supports an optional extra encryption layer beyond AES-GCM (e.g., ChaCha20-Poly1305 or hardware-bound HSM cipher). This structure enables agency-defined crypto policies while maintaining interoperability.

10. Attachments and metadata protection
Each attachment resides in its own independent AES-256-GCM capsule, keyed via a distinct ML-KEM shared secret. Compromise of one file reveals nothing about others. Subjects may be encrypted (“zero-leak mode”), BCCs are omitted. Even a compromised server learns nothing of content or participants.

 

11. Performance
● AES-256-GCM: hardware-accelerated, TLS-equivalent.
● ML-KEM-1024: < 2 ms (native), < 10 ms (WASM). Overall latency: ≈ 5–15 ms per message — imperceptible to users.

12. Scalability
● Stateless proxies enable horizontal scaling.
● Redis / PostgreSQL handle ratchet and session state.
● Multi-tenant architecture > 20 000 encrypted messages per node per hour.

13. Delivery latency
PQC handshake adds only one encapsulation (< 0.1 s per e-mail).

14. Key generation, storage, and distribution
● Generated locally: All keys (long-term, ephemeral, and DEKs) are generated client-side using WebCrypto, liboqs, and libsodium.
● Stored locally / client-side: DEKs are stored AES-256-GCM-encrypted, with keys derived from user credentials via HKDF-SHA-512 (20 000 iterations) and a unique salt. Even if storage is extracted, recovering plaintext keys is computationally infeasible without the correct credentials.
● Key Transfer Capsules (KTC): New devices are provisioned only through ML-KEM-encapsulated capsules from trusted devices; no secrets are ever transmitted in plaintext or stored server-side.
● Server awareness: The server never accesses DEKs or private keys — only encrypted blobs are synchronized.
Thus, all DEKs are securely persisted client-side, protected by AES-GCM and HKDF-derived keys, while KTC enables safe multi-device continuity without exposure of cryptographic material.

15. Quantum-safe key exchange & Double Ratchet operation
All key exchanges use ML-KEM-1024 (NIST PQC standard). Session keys evolve through a bidirectional Double Ratchet, covering both incoming and outgoing traffic.

● Forward secrecy: Used keys are immediately destroyed.
● Post-compromise security: Each message adds fresh entropy.
● Non-reversible: Ratchet chains are one-way hash-based — past keys cannot be recovered.
● Independent chains: Send and receive paths evolve separately.
Every message and file has its own non-recoverable key, making retroactive decryption impossible — even for quantum-capable adversaries.

16. Trust model
KeyPact follows a decentralized, zero-knowledge, no-master-key trust model, ensuring no external authority or hierarchy ever holds privileged access.
● No central PKI or key escrow: All trust derives from mathematical key agreements
— there are no master keys capable of decrypting user data.
● No key hierarchy: Each user and device operates with its own independent cryptographic identity; there is no root-of-trust or administrative override.
● Key Transfer Capsules (KTC): Temporary or multi-device key exchange occurs exclusively via ML-KEM-protected capsules between trusted endpoints, allowing
one-time sharing without revealing long-term keys.
● Peer-to-peer verification: Public keys are validated directly or through signed envelopes and out-of-band QR checks.
● Server non-involvement: The server only syncs encrypted capsules and never handles private or derived secrets.

This architecture ensures absolute digital sovereignty — no administrator, provider, or attacker can ever decrypt user data, even under compulsion.
We trust nothing — except mathematics. We design and build to resist.

Summary
KeyPact delivers a quantum-resistant, zero-knowledge communication platform for secure e-mail and file exchange. It integrates ML-KEM-1024, AES-256-GCM, and a bidirectional Double Ratchet, combined with Passkey / FIDO2 / YubiKey authentication for hardware-based identity assurance.
Every message and file uses its own unique key that never leaves the endpoint. An optional extra encryption layer is available for defense deployments. The current RSA/AES version is live and quantum-prepared; full ML-KEM production launch is set for 1 November 2025. Independent validation by NCC Group, followed by Common Criteria certification, is in progress.