Two-Party Computation Linkage is a Privacy-Preserving Record Linkage (PPRL) protocol where two parties use secure multi-party computation (SMPC) to compute the intersection of their datasets. Each party encrypts its identifiers and engages in a joint cryptographic function that outputs only the matched record pairs, ensuring no plaintext data is exposed to the counterparty or an external processor.
Glossary
Two-Party Computation Linkage

What is Two-Party Computation Linkage?
A cryptographic protocol enabling two data custodians to jointly identify matching records across their databases without revealing their full datasets to each other or a third party.
Unlike trusted-third-party models, this architecture eliminates the central honeypot risk by distributing the computation. The protocol typically combines private set intersection with secure string comparators like secure edit distance to tolerate typographical errors, allowing the parties to discover common entities while maintaining a formal, provable guarantee that non-matching records remain cryptographically invisible.
Key Features of Two-Party Computation Linkage
Two-Party Computation (2PC) Linkage enables two data custodians to jointly identify matching records without exposing their raw datasets. This protocol leverages cryptographic primitives to ensure that only the intersection is revealed, preserving the privacy of non-matching entities.
Cryptographic Secrecy Guarantee
The foundational property of 2PC linkage is that neither party learns anything about the other's dataset beyond the final matching records. This is achieved through garbled circuits or secret sharing, which ensure the computation reveals zero information about non-matching identifiers. Unlike trusted third-party models, this architecture eliminates the need for a central data aggregator, drastically reducing the risk of mass data exposure.
Secure Edit Distance Computation
To handle dirty real-world data, 2PC protocols often implement secure edit distance algorithms. This allows parties to compute the string similarity between private inputs without revealing the strings themselves.
- Levenshtein Distance: Calculates the minimum number of single-character edits required to change one word into another.
- Damerau-Levenshtein Distance: Extends the metric to include transpositions of adjacent characters. This enables fuzzy matching against typographical errors while maintaining cryptographic privacy.
Private Set Intersection (PSI) Foundation
Many 2PC linkage protocols are built upon Private Set Intersection (PSI) primitives. PSI allows two parties to compute the intersection of their sets without exposing elements unique to either party.
- PSI Cardinality (PSI-CA): A variant where parties learn only the size of the intersection, often used as a private blocking step before full linkage.
- Circuit-based PSI: Uses generic secure computation to compare encoded records, offering flexibility for complex matching rules beyond exact equality.
Garbled Circuit Evaluation
A dominant technique for implementing 2PC linkage is Yao's Garbled Circuits. One party (the garbler) encrypts a Boolean circuit representing the matching logic. The other party (the evaluator) computes the circuit using oblivious transfer to retrieve input keys without the garbler learning which inputs were selected. This ensures that the matching algorithm itself is executed securely, protecting both the data and the specific matching rules.
Scalability via Private Blocking
Naively comparing every record pair across two datasets is computationally prohibitive. 2PC linkage integrates private blocking to reduce the quadratic complexity without leaking plaintext similarity.
- Locality-Sensitive Hashing (LSH): Hashes similar encoded records into the same bucket with high probability.
- Reference Value Encoding: Uses a set of public reference strings to cluster records based on similarity to these anchors. This preprocessing step ensures the protocol remains feasible for large-scale health informatics and census applications.
Output Governance and Thresholding
The protocol strictly governs what is revealed at the end of the computation. A secure comparison yields a boolean result for each candidate pair, and only pairs exceeding a predefined match score threshold are output. This prevents the leakage of partial similarity scores. The final output is typically a list of matching record IDs, which can then be used to trigger a separate, authorized data exchange for the matched entities only.
Frequently Asked Questions
Explore the core concepts behind secure two-party record linkage protocols, where cryptographic techniques enable collaborative entity resolution without exposing sensitive plaintext data.
Two-Party Computation Linkage is a Privacy-Preserving Record Linkage (PPRL) protocol that enables two data custodians to jointly identify matching records across their respective databases using Secure Multi-Party Computation (SMPC) without revealing their full datasets to each other or a central third party. The protocol works by having each party first encode their sensitive identifiers—such as names, addresses, or dates of birth—into cryptographic representations like Bloom filters or homomorphic encryptions. These encoded records are then compared using a secure function evaluation that computes similarity metrics, such as Dice coefficient or edit distance, directly on the encrypted data. Crucially, the computation reveals only the matching record pairs to the authorized parties; non-matching records remain cryptographically protected. This approach eliminates the need for a trusted linkage unit, making it ideal for adversarial or semi-honest environments like cross-institutional healthcare research or financial fraud detection.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Two-Party vs. Multi-Party vs. Trusted-Third-Party Linkage
Architectural comparison of three record linkage paradigms based on participant count, trust model, and cryptographic guarantees.
| Feature | Two-Party Computation | Multi-Party Computation | Trusted-Third-Party |
|---|---|---|---|
Number of data custodians | Exactly 2 | 3 or more | 2 or more |
Trust model | Mutual distrust between parties | Honest majority or dishonest majority | Single trusted intermediary |
Full dataset revealed to third party | |||
Cryptographic guarantee | Simulation-based security proofs | Simulation-based security proofs | Policy-based, no cryptographic guarantee |
Non-matching records exposed | |||
Scalability ceiling | Quadratic comparison per party pair | Quadratic across consortium | Linear with central compute |
Single point of failure | |||
Regulatory compliance fit | GDPR, HIPAA (data minimization) | GDPR, HIPAA (data minimization) | Requires BAA or DPA with third party |
Related Terms
Understanding Two-Party Computation Linkage requires familiarity with the underlying cryptographic protocols, data structures, and matching methodologies that make private record linkage possible.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us