Today's HSM vendors don't ship a cryptographic engine, they ship a patchwork: one code path for RSA primes, another for NTT-friendly FHE parameters, another for zk-SNARK moduli, and soon a fourth for post-quantum migration. Four code paths. Four audit trails. Four optimization targets. Four places the performance ceiling gets hit.
Ethoryx ships the Unified Prime Engine: a single C core that serves every cryptographic primitive the HSM needs. Integrated through standard PKCS #11 C_GenerateKey(). Zero application changes.
The cryptographic engine inside a top-tier HSM today is a fragmented architecture: separate code paths for each primitive, each tuned independently, each auditable only in isolation. What looks from the outside like "a cryptographic module" is internally four silos that happen to share a chassis.
C_GenerateKey(mechanism)When a customer enables FHE operations alongside RSA, their throughput collapses to the weakest path. The RSA team can't optimize the FHE team's code. Each silo's ceiling becomes the product's ceiling.
FIPS 140-3 and Common Criteria certify code paths. Four silos mean four certifications, four re-certifications on every change, and four places a CVE can hide. Cost and time scale with silo count, not with capability.
As NIST PQC becomes mandatory through 2027, vendors must add a fifth silo. Each new silo is a new multi-quarter project. The patchwork cannot absorb post-quantum gracefully, it must be extended, audited, and re-sold.
Ethoryx consolidates prime-generation into a single C core with a single optimization target. RSA primes, NTT-friendly primes for lattice FHE, curve moduli, and post-quantum parameters all flow through the same engine. One code path. One performance story. One audit surface.
When we improve the engine, every primitive gets faster simultaneously. The RSA path and the FHE path share the same sieve, the same candidate selection, the same GMP calls. One optimization surface, not four.
FIPS 140-3 and Common Criteria evaluate one C core against one threat model. New primitives inherit the certification instead of requiring new ones. Audit cost becomes constant, not linear in silo count.
The engine treats prime generation as a single mathematical problem; finding integers that satisfy specified constraints. Adding a post-quantum primitive means adding constraints, not adding a silo. NIST PQC migration becomes a configuration change.
Enterprise applications already call C_GenerateKey(). They don't need to know which engine is behind the PKCS #11 interface. Ethoryx slots in underneath application code stays identical, the engine changes, performance and audit properties improve. Drop-in replacement, not migration project.
// Existing enterprise code not modified CK_MECHANISM mech = { CKM_RSA_PKCS_KEY_PAIR_GEN, NULL_PTR, 0 }; CK_OBJECT_HANDLE pubKey, privKey; C_GenerateKey(session, &mech, template, attrCount, &pubKey, &privKey); // ↑ This call used to take ~280ms on 4096-bit RSA. // With Ethoryx engine behind PKCS #11, same call, faster, auditable, PQC-ready.
Ethoryx engine integrates behind the HSM vendor's PKCS #11 layer. Application-visible API is unchanged.
CKM_RSA_PKCS_KEY_PAIR_GEN, NTT primes, curve moduli of all routed to the same engine with different constraints.
Engine carries its own FIPS / CC evidence. HSM-level certification incorporates Ethoryx artifacts rather than re-auditing from scratch.
Future primitives (PQC, new FHE schemes, emerging zk systems) added as engine configurations, no silo expansion, no new audit surface.
Measured on the Ethoryx reference engine under controlled evaluation. Customer-specific results vary by workload and hardware; request a technical evaluation for figures on your target configuration.
Ethoryx Research partners with HSM vendors and enterprise buyers on technical evaluation, integration pilots, and long-term engineering arrangements. If your roadmap includes PQC migration, FHE at scale, or simply reducing the audit surface of your cryptographic module, this is the conversation to have in 2026.