Questions, answered.
How encrypted compute and AI work in practice: security, performance, identity, verification, and how it fits your stack.
General & Security
By NIST SP 800-57, secp256k1 and P-256 provide 128-bit security (symmetric-equivalent), and P-384 provides 192-bit. These are infeasible to break with classical computers today.
No. Any slowdown comes from the computational cost of homomorphic operations, not from a weaker cipher, and it's addressed with parallel processing. Security strength is unaffected.
It depends on who is meant to see the result. If a party only runs operations on ciphertext, or the data owner decrypts the result, no public key is required. When an external party must read the result in the clear, or multiple parties run a joint analysis, we apply a key-splitting / MPC protocol so no single party ever holds the full key.
TorusDB & Homomorphic Encryption
We don't claim quantum resistance as a mathematical property of the cipher itself. Instead, TorusDB's No-Key architecture removes what a quantum attack would target: no public, evaluation, or secret key ever lives on the server, so there is nothing there for a Shor-style attack to derive. The server's view is designed to be information-theoretically independent of the plaintext, so even a quantum adversary has no key to break and no readable data to take. For quantum-resistant signing and authentication, PrivID adds a lattice-based layer (CRYSTALS-Dilithium, the NIST FIPS 204 standard) on top.
Yes. Homomorphically encrypted data doesn't reveal the size, order, or distribution of the plaintext, so a plain B-tree index no longer applies. TorusDB instead provides a token-based Secure Index that filters quickly while data stays as ciphertext, and uses parallelism to accelerate heavy queries.
Throughput scales with core count and parallelism, from single-core encryption to multi-node pipelines, and is tuned to your environment. Concrete figures for environments like ERP and SAP HANA are measured and shared through a PoC.
No. The team running analysis holds neither the plaintext nor a decryption key. Statistics, aggregation, conditional search, and segmentation run on ciphertext, and results are produced as ciphertext by default. When a final decryption is genuinely required, no individual holds the key alone. It's handled selectively via threshold key sharing / MPC / policy-based approval.
Column-level keys, role-based access, and a KMS are security policies: they govern who may access data. Homomorphic encryption is a compute technology that runs operations on ciphertext without decrypting it. They aren't competitors but complements. TorusDB's goal is to run statistics, aggregation, matching, and analysis without ever exposing plaintext.
No. The proxy never decrypts plaintext. It applies security policy, routes ciphertext, manages compute requests, audit logs, permission checks, and key-access design. Both the server and the proxy hold no plaintext and compute on ciphertext.
Strings are supported. The real value for string data is privacy-preserving matching: customer matching, deduplication, secure join, segmentation, identity resolution, overlap analysis, and fraud detection can all run on ciphertext without exposing the plaintext.
We have measured throughput for single-condition queries. For multi-condition combinations, results are measured and shared through a PoC run on your own data.
AI on Encrypted Data
No. Your documents stay encrypted end to end. Relevant chunks are retrieved as ciphertext, and an LLM gateway ensures no plaintext reaches an external model. The model receives only the grounding it needs to answer, never the raw text.
An LLM gateway sits between your data and any external model and prevents plaintext from leaving the encryption boundary. Retrieval and grounding happen inside that boundary, so the model gets only what it needs. Nothing sensitive leaks.
Agents act only within pre-defined permissions and policy. Every action is recorded so it can be verified and audited after the fact. You can always see what an agent did and why it was allowed to.
No. Agents operate without plaintext exposure: sensitive data is tokenized at the gateway or processed in-house, and only de-identified content ever reaches an external model. Automation never requires handing over plaintext, so you avoid the usual trade-off where automating more work widens your exposure surface.
Passwordless Identity (PrivID)
Instead of a shared secret, you prove who you are with a key you hold. No password is stored on the server, which removes an entire class of account-takeover risk: credential leaks, reuse, and phishing.
The same person can authenticate to different services with identities that can't be correlated to one another. Even if those services pool their data, they can't easily link the activity back to a single individual.
For PrivID it means quantum-resistant signing. The signature layer is built on CRYSTALS-Dilithium, the NIST FIPS 204 lattice standard, so signatures stay unforgeable even against a full-scale quantum computer. It also has graceful degradation: even if the classical elliptic-curve layer were broken, signatures still can't be forged. To be precise, that quantum guarantee applies to unforgeability. The identifier-privacy layer still rests on classical assumptions today, so this is a transitional hybrid rather than full post-quantum privacy, which is a defined roadmap item.
Verification & Quantum Resistance (Moduli Chain)
At two layers, yes, with an honest boundary. Data layer: TorusDB's No-Key architecture removes the keys a quantum attack would target, so there is nothing on the server for a Shor-style attack to break. Signing and authentication layer: PrivID uses CRYSTALS-Dilithium (the NIST FIPS 204 standard), so signatures can't be forged even by a quantum adversary. The one thing we don't overclaim is identifier privacy in the identity layer, which is still classical today and is on the roadmap toward full post-quantum privacy.
Yes. Moduli Chain records each privacy-preserving operation as a cryptographic proof, so regulators, partners, and auditors can independently verify the correctness and integrity of a result without ever seeing the underlying data.
Compatibility & Deployment
It supports Oracle, MSSQL, SAP HANA, PostgreSQL, and MySQL, and applies while preserving column formats, so no ALTER TABLE is required (schema-preserving). On-premises installation is supported as needed.
Homomorphic encryption is recognized as a privacy-enhancing technology, and formal product-level certification is being prepared. We pursue objective validation through accredited testing and support compliance with the applicable regulations for your industry.