"Building CryptoFlex: An Offline, Quantum-Safe Policy Engine for Python 🔐"

Most modern post-quantum cryptography (PQC) discussions focus heavily on live network traffic—like Signal’s PQXDH or Chrome's X25519Kyber768. But what about local, offline, file-based applications? Desktop tools, local backup vaults, and offline embedded/IoT systems are often left hardcoding legacy cryptographic stacks. If that math gets broken or weakened in the future, the whole application requires a painful, massive rewrite. To explore a solution, I built CryptoFlex: an open-source, local-first crypto-agility policy engine for Python 3.10+. Crypto-agility means your application can dynamically swap its underlying encryption primitives without breaking your core application logic or requiring a code redeploy. cryptoflex doesn't invent new math. Instead, it orchestrates existing, trusted primitives—classical X25519 and post-quantum ML-KEM (via liboqs)—behind a localized decision engine. [ Application Code ] ↓ 🔐 CryptoFlex PolicyEngine ↓ [ Evaluates Local Environment Signals ] ↓ [ Selected Crypto Profile ] (e.g., X25519 + ML-KEM-768 Hybrid) Zero External Dependencies: No phone-home analytics, no cloud configuration servers, and zero network calls. It operates entirely on-device. Self-Describing Versioned Headers: Every encrypted file retains the profile information that generated it, ensuring old data remains readable even if your application's default security requirements scale up later. Graceful Degradation: If a constrained system fails to compile full PQC binaries, it safely signals a degraded=True status back to your logs instead of crashing your app (unless you strictly enforce require_quantum_safe=True). RFC 9954-Inspired Key Combiner: Secrets and ciphertexts are bound together via HKDF derivation so the resulting key remains as strong as the single strongest untouched primitive. Full Disclosure: This project is at version v0.1.0 and has not undergone an independent, third-party security audit. While the underlying primitives (X25519 and liboqs-python) are thoroughly vetted, this orchestration layer itself is fresh code. Please do not drop this into production environments where you cannot afford implementation bugs. Instead, I am treating this as an architectural blueprint and an open invitation for collaboration. If you love Python architecture or applied cryptography, I would highly value your feedback on the repository. Specifically: The Combiner Logic: Does our HKDF implementation tightly bind the classical and post-quantum secrets as intended? The Policy Fallback: Are there edge cases where the graceful degradation mode could fail silently? Check out the code, open an issue, or rip the architecture apart in the comments below! 📦 GitHub Repository: keerthivasan-sankar/crypto_flex #python #security #architecture #showdev