Encrypted vector scoring, with the evidence attached.

What we set out to achieve

Our goal was to narrow the performance gap between encrypted scoring and ordinary computation. Specifically: could a defined vector-scoring workload run in less than 10× the time of an equivalent plaintext calculation, including client decryption and decoding?

In the archived GPU experiment, the local pipeline scored 4,096 records with 32 features each in approximately 0.260 milliseconds—9.85× the fastest plaintext control tested in that run. That met the relative target for this workload. [1]

The result assumes a prepared encrypted database and public queries, excludes setup and network transport, and still needs independent reproduction. The fresh CPU experiment did not meet the 10× target. Our longer-term aim is to help make useful computation over protected records more practical; this release provides a bounded experiment others can test and improve.

Where the technology stood—and what this research adds

Computing on encrypted numbers was already possible. The original CKKS paper, published at ASIACRYPT 2017, established approximate arithmetic on encrypted values. Libraries such as Microsoft SEAL make that capability available to developers. This release builds on that foundation.

The practical step is a working engineering reference for evaluating encrypted scoring: prepared records, public queries, a complete local reply path, and plaintext controls with corresponding preparation benefits. Researchers can use it to reproduce the result, locate bottlenecks, and test alternative implementations. [2]

The 9.85× figure compares encrypted execution with plaintext in the same archived experiment. It is not a measured speedup over previous CKKS systems, and the release does not establish a field-wide performance record.

Where could this lead? If independent testing supports the result and the approach transfers to real workloads, it could inform encrypted scoring components in larger similarity-based systems. Testing that transfer—including networking, security boundaries, and retrieval integration—is the next step.

How the idea took shape

The project began with an ambitious question: could encrypted computation get close enough to plaintext speed to become practical for everyday use? That ambition started a much narrower, testable investigation.

Our early discussions explored ideas across disciplines. Could we trade computation for storage by precomputing answers? Could repeated queries reuse earlier work? Could a different representation remove expensive operations altogether?

One suggestion was a giant encrypted lookup table: replace calculation with retrieval. It was an exploratory idea, not the architecture we ultimately released. But it sharpened the question that guided the experiments: what can we prepare once, and what actually needs to change with each query?

Nature offered a useful analogy. An organism responding to a changing environment already has structure, memory, and specialized systems to draw on. We used that perspective to ask how software could preserve useful work, respond to change, and assign tasks to the components best suited to them. These were research heuristics, not biological mechanisms implemented in the software.

We thought of the approach as hybridization: combining techniques that solve different parts of the problem. We explored algebraic simplification, reuse across structured queries, specialized CPU and GPU execution, and a native client path for processing encrypted results. The workload became concrete: scoring encrypted database vectors against public queries.

The measurements redirected the work. As server computation became faster, client processing became the dominant cost. A GPU helped one execution path without automatically improving another. Each experiment changed where we looked next.

The process combined human research direction with AI-assisted implementation, measurement, and revision. It produced the specialized CKKS pipeline documented here. The broader lesson is a method: borrow across disciplines, turn analogies into testable questions, and let measurements decide which combinations are useful.

Who this research is for

• FHE developers and performance engineers investigating CPU/GPU execution, ciphertext handling, and client decoding. The raw measurements and implementation offer a concrete workload for comparing where time is spent.
• Vector database and ML infrastructure teams exploring encrypted distance scoring as one component of a larger system, where public queries are acceptable. The immediate question is whether this approach fits their data, accuracy requirements, and deployment constraints.
• Independent researchers who want to reproduce the measurements, challenge the plaintext controls, or test improvements on different hardware.

Examples of relevant industry work

Microsoft SEAL provides open-source tools for computation on encrypted data. Engineers working in that area could use this release as a workload to study packing, evaluation, and client-side overhead.

Pinecone builds vector similarity-search infrastructure, while Weaviate documents optimized distance calculations, including squared Euclidean distance. Teams tackling those problems could investigate whether an encrypted scoring stage is useful within a broader retrieval system. This experiment does not implement their indexes, establish compatibility, or demonstrate performance on their production workloads.

These are examples of relevant technical domains, based on the companies’ linked publications. Potential applicability is our assessment; no involvement, endorsement, or planned adoption by these companies is implied.

Its immediate value is a working foundation for benchmarking and prototyping. Production use requires further integration, deployment testing, and security review.

Interested in reproducing the results or discussing an application? Contact Erik Groset at erik@ipoq.com.

A specific question, not a claim about all encrypted computing.

Can we efficiently score a public query against a prepared, encrypted collection of vectors? This experiment evaluates 4,096 squared Euclidean distances over 32 real features per record. The records are encrypted; the query is public. The client receives and decodes every score. [1]

CKKS is an approximate homomorphic-encryption scheme: it supports arithmetic on encrypted numeric data. Here, the implementation specializes a familiar distance identity:

The database is prepared in advance. Each feature is packed across the records, and encrypted squared norms are precomputed. The public query supplies the coefficients for the remaining calculation. The plaintext controls receive corresponding preparation benefits, making that boundary explicit on both sides. [2]

Why is this interesting? Distance scoring is a building block for similarity-based systems. This release offers a testable starting point for exploring that building block under encryption. It is not yet a search product: private queries, approximate-nearest-neighbor indexing, top-k retrieval, and general-purpose computation are outside its scope.

Two reported results. Two different execution environments.

The release presents an archived GPU experiment and a fresh CPU experiment. They are not a controlled GPU-versus-CPU comparison, and the GPU timing was not rerun during the release audit. [3]

Overhead is encrypted time divided by the fastest tested plaintext control in the same experiment. Lower is better. These are local research measurements, not service-latency guarantees or a universal measure of FHE performance.

Each headline is the median of five per-key medians; each per-key value aggregates three blocks of 64 requests with 16 rotating queries. The ratio divides the aggregate encrypted and plaintext medians. The raw samples remain available. [4] [5]

The archived GPU result met a relative 10× threshold against its contemporaneous control. It did not meet the earlier absolute target of 234.93 µs. Independent reproduction remains outstanding. The fastest tested control is not a claim that no faster plaintext implementation exists.

The timing boundary is part of the result.

A small evaluation kernel is only part of a usable response. This benchmark times the local path through query preparation, evaluation, full reply construction, validated ciphertext import, decryption, decoding, and an independently owned array of all 4,096 results. GPU runs also include synchronous device transfers. [1]

The complete uncompressed ciphertext reply is 393,329 bytes. Network bandwidth, queueing, and service isolation could materially change a deployed system's latency. The local measurement should not be read as remote end-to-end performance.

A release designed to be questioned.

The repository includes raw timings, native CPU and optional CUDA implementations, pinned native dependency sources, validation cases, and a separate score receipt. The fresh release audit reports 2,828 differential import cases and 327,680 exact CRT reconstruction and conversion checks. Those are finite engineering checks, not a security proof. [3]

You can examine the supplied evidence using Python's standard library, without compiling the native engine. From a local checkout of the repository:

python3 scripts/audit_evidence.py
python3 -m unittest discover -s tests -v
python3 verify_receipt.py evidence/audit/cpu_receipt.json

The separate receipt verifier recalculates 65,536 scores. Checking a receipt or checksum does not authenticate execution on a remote machine. Building and rerunning the experiment is a separate step; the README documents hardware, dependencies, CPU instructions, and optional CUDA requirements.

What remains to be demonstrated.

The next useful work is independent reproduction on other hardware, stronger plaintext controls, real workloads, deployment testing, and independent cryptographic review. The original GPU evidence also lacks a historical CUDA-source digest; the release cannot retroactively attest to that binary. [3]

The benchmark deliberately keeps plaintext, keys, and both roles in one process for validation. It does not establish deployment isolation, query privacy, malicious-server resistance, or production security. The release's security scope spells out those limits. [6]

We are publishing the implementation so other researchers and engineers can inspect it, find defects, reproduce the results, and build on the work. Original code is Apache-2.0; original documentation and evidence are CC BY 4.0, with upstream materials retaining their own licenses. Permitted commercial reuse of this release does not require a separate IPOQ fee. See the repository's licensing terms.