Homomorphic encryption has been the "five years away" technology for two decades, but the past three years have changed the tempo. Microsoft SEAL 4.1, OpenFHE 1.2, Zama's tfhe-rs 0.8 and concrete-ml 1.7, and IBM's HElib 2.3 are all production-grade libraries, and schemes like CKKS (Cheon-Kim-Kim-Song, 2017) and TFHE (Chillotti-Gama-Georgieva-Izabachène, 2016) have specific use cases where HE is now genuinely practical rather than aspirational. Software supply chain security has obvious surface area for privacy-preserving computation: sharing vulnerability signals without sharing customer inventories, joint SBOM analytics between suppliers and buyers, and private set intersection for dependency overlap. This post walks through what HE can and cannot do in that space in late 2025, with measured numbers from public benchmarks rather than aspirational claims.
What does homomorphic encryption actually enable?
Computation on encrypted data without decryption. More precisely: given a ciphertext Enc(m) under a public key, an evaluator can produce Enc(f(m)) for some function f without learning m, and the original key holder can decrypt the result. Fully homomorphic schemes support arbitrary circuit depth by periodic bootstrapping; leveled schemes support bounded depth without it. For supply chain, the canonical use case is: a buyer wants to ask "does my supplier's software contain any of these 10,000 CVE-affected components" without sending the component list in the clear and without learning any component not in the buyer's query. This is a private set intersection problem that HE can solve, and that signed-but-plaintext SBOM exchanges cannot.
Which schemes fit which supply-chain workloads?
BFV and BGV fit integer comparisons; CKKS fits approximate arithmetic; TFHE fits bit-level boolean circuits and fast bootstrapping. BFV (Brakerski-Fan-Vercauteren) and BGV (Brakerski-Gentry-Vaikuntanathan) are the go-to for exact integer and modular arithmetic and are what Microsoft SEAL 4.1 defaults to. CKKS supports approximate real/complex arithmetic, which is useful for privacy-preserving statistics over vulnerability data but introduces controlled error. TFHE, as implemented in tfhe-rs 0.8, is optimized for programmable bootstrapping and is the fastest current scheme for low-depth boolean operations, which maps naturally to SBOM-component-membership checks. For set intersection specifically, TFHE or BFV with batching via plaintext slots (CRT packing) tend to outperform CKKS because the native operations are discrete.
What does performance actually look like in 2025?
Order-of-magnitude slower than plaintext, but increasingly viable for batch workflows. Benchmarks published with the OpenFHE 1.2 release show BFV multiplication at roughly 2 to 10 milliseconds per operation with parameters (N=16384, log(q)=438), BGV addition in sub-millisecond range, and TFHE programmable bootstrapping at 10 to 80 milliseconds on an AMD EPYC 7763. For a private set intersection over 10,000 CVEs against a 1,000-component SBOM using the PSI-CA protocol from Chen-Laine-Rindal with BFV batching, end-to-end time on commodity hardware is in the single-digit seconds, which is usable for a release-gate check but not for per-build inline evaluation. Ciphertext sizes are the other cost: a BFV ciphertext with typical parameters is 1 to 4 MiB, which multiplies bandwidth for any protocol that sends many of them.
Where is HE actually being used in supply chain or adjacent contexts?
Federated vulnerability analytics pilots, regulatory data sharing, and privacy-preserving telemetry. The US Census Bureau's 2020 disclosure avoidance used differential privacy rather than HE, but later pilots around medical data (for example the Mayo Clinic and Duality Technologies collaborations) used CKKS for cross-institution analytics. In software supply chain specifically, Linux Foundation's Confidential Computing Consortium has demonstration projects using OpenFHE for private set intersection over vulnerability feeds; these are not yet production in most commercial vendors. OpenMined's PySyft 0.9 wraps several HE libraries for ML use cases, and MP-SPDZ 0.3 supports mixed HE and MPC protocols for joint analytics. The honest state: pilots exist, production supply-chain HE deployments are rare outside highly regulated contexts.
What are the real barriers to broader adoption?
Parameter selection, key management, and the scarcity of engineers who can reason about FHE correctness. Parameter choice (polynomial degree, modulus chain, security level against the LWE estimator) is a subtle exercise where errors lead to either insecurity or failed decryption. Key management adds complexity: evaluation keys, relinearization keys, and bootstrapping keys are each megabytes to gigabytes in size and must be distributed under appropriate access controls. Debugging HE code is painful because intermediate values are opaque by design. Standardization is underway through ISO/IEC 18033-8 and the HomomorphicEncryption.org community standard, which codifies recommended parameter sets at 128-bit, 192-bit, and 256-bit security; teams should start there rather than rolling their own.
How Safeguard Helps
Safeguard supports private-intersection style queries against its vulnerability and compromised-package feeds via a standard HTTPS API today, and we are tracking HomomorphicEncryption.org-standard parameter sets for future opt-in private-query modes where customers require that queried CVEs or component names never leave their boundary in plaintext. For customers with strict data residency or multi-supplier confidentiality requirements, Safeguard's audit logs and policy framework can be scoped per tenant so shared-services analytics operate only on declared-public metadata. The practical default remains signed, transparent SBOMs with tenant-scoped access controls, with privacy-preserving compute available where threat models demand it.