PrivaDEX

What it is

A confidential computation engine that matches crossing trades directly over homomorphically encrypted records, eliminating information leakage without exposing order prices, quantities, or trader identities to the matching host. Orders are encrypted under a hybrid scheme using Microsoft SEAL before leaving the client, processed homomorphically through SIMD batching, and resolved so that only matched outcomes are revealed to designated counterparties.

What was hard

Evaluating integer equality and continuous sign checks under homomorphic encryption with strictly bounded multiplicative depth. The engine coordinates two schemes over a fixed 16-order geometric slot layout (stride 512, degree 16,384): BFV for exact price equality checks, and CKKS with a degree-27 polynomial approximation for continuous sign evaluations aligned to depth 4. Preventing side-channel leakage across concurrent requests required eliminating shared class-level accumulator buffers, enforcing sequential rotation loops to avoid race conditions in thread pools, and verifying slot-blinding identity transformations so that internal matrix representations reveal nothing to the server.

What was measured

End-to-end homomorphic batch execution was measured across 100 iterations of 16-order batches in C++, achieving a mean latency of 38.53 ms and a 99th-percentile latency of 45.16 ms against an enforced gate of 150 ms. Correctness and noise budget invariants were verified across 14 regression tests covering noise-budget preservation at depth 4, deterministic BFV equality, and slot-blinding identity invariants.

Constant-time discipline

Side-channel safety here isn’t limited to the homomorphic evaluation path — the same discipline applies to any modular arithmetic touching a secret. In discrete-log signature schemes (DSS/DSA), a non-constant-time modular inversion or scalar exponentiation can leak bits of the secret nonce k through CPU execution timing or cache-line collisions. Leaking even a few bits of k across ~100 signatures is enough to recover the full private key via lattice reduction (the Hidden Number Problem).

The fix is to compute the inversion k⁻¹ mod q = k^(q-2) mod q via a Montgomery ladder with a static branch profile, so every bit of the exponent takes the same code path regardless of its value:

// DSS signature: s = k⁻¹ · (H(m) + x · r) mod q
// Zero branch divergence or secret-dependent lookup
template <typename ModulusQ>
constexpr uint64_t ct_dss_inv(uint64_t k, uint64_t q) {
  // Fermat's Little Theorem: k^(q-2) mod q
  uint64_t result = 1;
  uint64_t base = k;
  uint64_t exp = q - 2;
  for (int i = 63; i >= 0; --i) {
    result = ct_mul_mod(result, result, q);
    uint64_t bit = (exp >> i) & 1ULL;
    uint64_t mult = ct_mul_mod(result, base, q);
    result = ct_select(bit, mult, result);
  }
  return result; /* 0 timing delta */
}

The same constant-time rules — no secret-dependent branches, no secret-dependent memory indexing — carry over directly to the Galois rotations and slot-blinding transforms this engine relies on to keep intermediate values invisible to the matching host.

What is still open

The system currently relies on an off-engine settlement bridge to commit finalized match events to an external ledger. Scaling the batch size beyond 16 orders requires evaluating higher-degree polynomial context chains or multithreaded Galois key rotations, as noise budget consumption at depth 4 limits further composition without bootstrapped re-encryption.