Privacy and cryptography engineering
CorpiXo designs end-to-end encryption, key management, and data-minimizing architecture for systems where the server should not be able to read what it stores. Zero-knowledge proof integration is production work in this practice; homomorphic encryption is feasibility-stage, and every claim on this page is marked accordingly. The distinction matters more here than anywhere else on this site, because the cost of an overstated claim in this practice is a client's users trusting a guarantee that doesn't hold. A system that is 'private by policy' and one that is private because the server has no key are different designs, and only the second is what this practice builds toward.
What we build
The first four items below are things we build; the fifth is something we assess, and we don't blur the line between the two. A feasibility report that reads like a sales pitch for the technology it's evaluating isn't a feasibility report.
- End-to-end encryption design — key exchange, envelope encryption, and key rotation — specified before implementation starts (production)
- Key management architecture, including recovery paths that don't reintroduce server-side access to plaintext (production)
- Zero-knowledge proof integration into an existing application flow: proof generation, verification, and the UX around proving time (production)
- Data-minimizing architecture review — what the system currently stores that it doesn't need to, and a plan to remove it (production)
- Homomorphic encryption feasibility work — whether a specific computation can run over encrypted data within an acceptable performance budget, assessed rather than assumed (feasibility-stage)
Stack
End-to-end encryption · Envelope encryption · Zero-knowledge proofs (production) · Homomorphic encryption (feasibility)
Where a claim above is marked feasibility-stage, the stack entry carries the same label — the label lives with the claim everywhere it appears on this page, not just once at the top.
How this is usually scoped
Encryption and key-management design is usually its own fixed-scope phase, separate from the application feature work that depends on it, since getting key management wrong is expensive to unwind later — a recovery flow that quietly reintroduces server-side plaintext access is a design defect, not a bug to patch after launch. Homomorphic encryption work is scoped as a feasibility phase with a defined question to answer, not as build work — moving to production build only if the feasibility phase shows the performance budget holds, and stopping there, with a written report, if it doesn't.
What you receive at handover
For design work, handover is a document a client's own engineers can implement against; for feasibility work, it's a report they can make a real decision from. Neither is a verbal summary — both are written artifacts the client keeps regardless of what they decide to build next.
- Design documentation: threat model, key-management architecture, and the assumptions it depends on
- Reference implementation and its test suite
- For feasibility work: a written report with reproducible benchmark numbers, stating what was measured, what was estimated, and what was assumed
- Repository access and documentation the client's own engineers can act on without CorpiXo
Frequently asked questions
- Do you audit our existing cryptography?
- No. CorpiXo verifies its own work as it's built, through threat models and test suites produced during delivery. We don't offer a standalone review or sign-off on a system we didn't build.
- Is homomorphic encryption production-ready for our use case?
- That's usually the question a feasibility phase answers, not something we'll claim up front either way. The phase's output is a written report with reproducible numbers, so the client can decide with real data rather than a vendor's assurance, including a clear no if the numbers say no.
- What does "the server can't read user content" actually mean in practice?
- It means the server never holds a decryption key for that content — encryption and decryption happen on the client, and the server stores and moves ciphertext it's structurally unable to open. It doesn't mean the server is undefended; it means a server compromise doesn't expose plaintext, which is a meaningfully smaller blast radius than most systems have by default.
- Can you integrate zero-knowledge proofs into an app that already exists?
- Yes — that's the more common starting point. The proof system usually needs to fit around an existing user flow, rather than the flow being designed around the proof system, which is as much a UX design problem as a cryptographic one.