Sharing Crypto Hardware Between Encryption-You-Can-Compute-On and Post-Quantum Key Exchange

BGV homomorphic encryption and ML-KEM share lattice math. This paper asks: can one embedded chip do both? Proof-of-concept says yes, with a concrete parameter selection.

Imagine you own a restaurant kitchen with two chefs who both need an oven. One chef bakes bread (ML-KEM — the new post-quantum key exchange standard), the other makes soufflés (BGV — a fully homomorphic encryption scheme that lets you compute on encrypted data). Both use the same oven physics — heat, convection, timing — but they've always demanded separate ovens because their temperature profiles differ. This paper asks: can we build one oven that serves both chefs, switching modes as needed? The committed claim is that BGV (a fully homomorphic encryption scheme) and ML-KEM (the NIST post-quantum key encapsulation standard) share enough lattice-based mathematical structure — specifically, both rely on variants of the Learning With Errors problem over polynomial rings — that a single embedded hardware implementation can execute both, with parameter sets chosen to satisfy the security requirements of each. The authors call this "agile" cryptography: one platform, multiple protocols, switchable at runtime. This is not a performance paper. There are no benchmark races, no throughput comparisons against dedicated ASIC implementations. The contribution is architectural: showing that the polynomial arithmetic core (NTT transforms, modular reductions, polynomial multiplications) required for BGV and ML-KEM can be unified in a shared datapath. The parameter selection — choosing ring dimensions, moduli, and error distributions that are valid for both schemes simultaneously — is the actual technical work. They target embedded use cases, meaning resource-constrained devices like medical sensors or wearable health monitors where running two separate crypto stacks is prohibitively expensive. The ladder is thin. The paper does not name a specific competing implementation and compare cycle counts, area, or power consumption. There is no head-to-head against, say, a dedicated BGV accelerator plus a separate ML-KEM core. The proof-of-concept demonstrates feasibility — it works — but does not demonstrate superiority over the naive alternative of simply running two separate implementations. For embedded contexts, the area and power savings of unification are the implicit argument, but those numbers are not provided. Integrity-wise, this is a proof-of-concept paper, and it is honest about being one. The validation is a working implementation that demonstrates the parameter sets are compatible and the shared arithmetic pipeline produces correct results. There is no formal security proof beyond referencing the known hardness of the underlying LWE variants. The health data framing is motivational context, not a validated deployment — no real patient data was processed, no medical device constraints were tested. The milestone question is concrete: for this approach to matter practically, someone needs to tape out a unified lattice-crypto chip and measure its area/power/throughput against separate-core designs on a real embedded platform. The gap between "we showed the math works" and "here's a chip" is probably 2-4 years of engineering, assuming interest from the embedded security community. The unlock is meaningful: post-quantum-safe health data processing on devices too small for two separate crypto engines. The obvious experiment not run is a full hardware synthesis (FPGA or ASIC) with area and power measurements. The honest read is (a): this is likely a resource constraint. The authors are presenting the algorithmic unification as the contribution; the silicon implementation is the next paper. Whether that next paper exists depends on whether the embedded security community picks this up.