Secure multiparty computation can turn a shared question into a limited exchange rather than a new data warehouse. The difficult decisions concern the question, the participants and the answer.
The collaboration that nobody wants to host
Imagine a group of independent food cooperatives trying to discover whether they can share refrigerated deliveries. Each knows its own orders, destinations and available capacity. None wants to give a competitor its complete customer list or let a new intermediary accumulate a permanent map of its business. They nevertheless have a reasonable joint question: which proposed routes have enough compatible demand to justify further discussion?
This is a hypothetical example, not a report of a deployed service. It exposes a practical distinction. The cooperatives need an answer to a particular question. They do not necessarily need one another's databases. An ordinary project can blur those requirements by collecting everything first and deciding what to calculate later. Secure multiparty computation, usually shortened to MPC, begins with the possibility of separating them.
The subject has a timely institutional backdrop. NIST's January 2026 call for multiparty threshold schemes requests technical specifications, reference implementations and experimental evaluations. Threshold cryptography distributes operations involving a secret key across parties; it is a particular application of ideas related to MPC, not a synonym for every collaborative database analysis. The call is a process for gathering and evaluating material, not a declaration that any product using the term is certified. NIST IR 8214C
For readers evaluating a public-interest project, the important question is less dramatic than whether mathematics can abolish trust. Which information must the participants share, which authority must somebody retain, and which risks remain after the calculation? A useful answer can be substantially smaller than a database. It can also reveal more than its designers intended.
The following analysis separates reported research from an original design exercise. The cooperatives are invented to make the decisions concrete. Proposed safeguards are editorial recommendations to examine with qualified implementers, not a claim that a few paragraphs specify a secure protocol.
Start with the output, not the upload form
In the research formulation, MPC allows parties with private inputs to jointly compute a specified function while limiting what the execution reveals beyond their authorized outputs. A comparison with an ideal trusted party helps define the objective: imagine someone who receives the inputs, faithfully performs the agreed calculation and returns only the appropriate results. The actual protocol attempts to provide comparable guarantees under stated assumptions, without simply handing that trusted role to a single ordinary recipient. Bogetoft and colleagues, Secure Multiparty Computation Goes Live
That formulation makes the output specification unusually important. Our imagined cooperatives could ask for the total demand on every street, the identities of all potentially compatible partners, or a simple notification that a proposed district has sufficient demand. Those are different services. They expose different information even if the underlying calculations are perfectly protected.
Suppose a pilot's actual purpose is to decide where to hold a planning meeting. Publishing a ranked list of every customer's delivery requirements would be disproportionate to that purpose. A district-level invitation may suffice. Conversely, if the next step is to allocate specific vehicle slots, a vague citywide indicator will not do the work. Privacy cannot be evaluated independently of what someone needs to accomplish.
A project team should therefore write a sample output before building an input portal. Give the sample to the intended recipient and ask what action it enables. Give it to someone whose data would contribute and ask what it might expose. If the two conversations reveal a disagreement, encryption has not resolved it. The disagreement belongs in the design specification.
An output-first approach also makes unnecessary fields conspicuous. If the pilot never uses customer names, collecting them introduces an avoidable dependency. If exact addresses are required only at a later stage involving a consenting pair of partners, they need not automatically enter the preliminary consortium-wide computation.
A share is not a redacted record
Secret sharing is one important building block. Adi Shamir's 1979 construction distributes a secret into pieces so that a specified number can reconstruct it, while a smaller collection reveals no information about its value within the construction's mathematical setting. This is not the same as dividing a spreadsheet into readable rows or blacking out names. The pieces are mathematical encodings, and the security claim depends on how they are generated and which combinations an adversary obtains. Shamir, How to Share a Secret
For the cooperatives, this distinction changes the infrastructure discussion. A server holding shares is not simply a custodian of one district's plainly readable orders. But calling the contents shares does not make the server irrelevant. Its administrators, backups, authentication mechanisms and relationships with the other operators still belong in the threat model.
It is tempting to draw three boxes and label them independent. The drawing proves nothing about independence. If one contractor controls all three administrator accounts, a distributed diagram may conceal concentrated authority. If the operators have separate ownership but use one shared recovery service, that service deserves attention too. The useful review question is which actor can cause which pieces of information or control to come together.
A nontechnical participant should be able to ask that question without learning the proof. They should receive a specific answer rather than an assurance that the system is decentralized. A deployment description might identify the organizations operating the computing parties, explain their distinct access controls and state the coalition against which confidentiality is intended to hold. Those statements can be challenged and audited.
The diagram accompanying this article deliberately shows separate roles and a bounded output. It is a conceptual map, not a depiction of a particular secure protocol. A map can help a reader locate responsibility; it cannot replace the protocol's analysis.
Who supplies data, who computes, who learns?
Conceptual role map; not a protocol specification. Privacy during computation, input quality and output disclosure require separate assessments. Sources linked in article. Prepared 1 November2026.
An MPC project may involve many data contributors but relatively few computing parties. The people represented in a dataset may be neither. The result recipient can be another role again. Confusing these groups makes a privacy claim almost impossible to interpret.
Research on accessible privacy-preserving analysis provides a useful deployed example. A 2018 paper by Lapets and colleagues describes web-based systems for pay-equity analysis and spending involving local and minority-owned businesses. The authors emphasize usability for participants with limited technical resources and distinguish resource-constrained contributors from parties doing more computation. The paper reports implementation experience; it does not establish that every later service with a browser interface has equivalent protections. Lapets and colleagues, COMPASS 2018
For the hypothetical delivery pilot, the cooperative submitting an order summary is a contributor. A university, a cooperative federation and another agreed operator might be computing parties. A planning committee could receive approved district-level results. Customers whose orders contributed are affected people, even if they never see the interface. Listing those four roles prevents the word participant from carrying contradictory meanings.
This role map should also specify who can change the calculation. An operator allowed to maintain a machine should not automatically be assumed to have authority to expand the query. A committee authorized to receive one output should not silently gain access to every intermediate result. A contributor's ability to withdraw from future rounds should be distinguished from the impossible promise of making already released information disappear.
Responsibility becomes clearer when each role has a short statement: what it provides, what it can observe, what it can authorize and what happens when it leaves. These statements are practical governance proposals, not extra cryptographic theorems. Their value is that a project can inspect them before sensitive data enter the system.
The threat model is part of the product
Different protocols make different assumptions about adversaries. Some consider parties that follow the protocol but try to infer additional information from what they observe. Others address parties that deviate from the instructions. The number or proportion of compromised participants also matters. Keller's MP-SPDZ framework paper explicitly spans different security models and computational representations, illustrating why the phrase uses MPC is not a sufficiently precise product specification. Keller, MP-SPDZ
A procurement conversation should translate those distinctions into ordinary institutional possibilities. Could an operator alter a message? Could two operators cooperate against a third? Could a contributor enter a fabricated value? Could a participant stop responding after learning something useful? Those are separate questions, and one reassuring answer does not settle all the others.
In our delivery exercise, consider an operator that is trusted to follow the software but not trusted to browse customer records. That is a different arrangement from one designed to tolerate an operator deliberately changing its behavior. Neither can be described honestly by saying nobody has to be trusted. The relevant assumptions must fit the relationship the participants actually have.
A simple way to test communication is to ask the implementer for a failure sentence. For example: this confidentiality guarantee does not cover a coalition larger than the specified bound. Another might concern compromised contributor devices or information intentionally included in the released result. A sentence that names a boundary is more informative than a paragraph of impressive vocabulary.
The governance team should then decide whether that boundary is acceptable for the proposed task. If it is not, the options include another protocol, different operators, a narrower question, less sensitive inputs or abandoning the project. Pretending the boundary does not exist is not a sixth option.
Valid inputs are not necessarily truthful inputs
A computation can faithfully process misleading data. This is especially easy to overlook when cryptography supplies an unusually strong guarantee about some other part of the workflow.
The 2025 SCIF paper studies secure aggregation with input validation and stronger guarantees in the presence of malicious actors. Under its stated condition that fewer than one-third of servers are malicious, it addresses output delivery and inclusion of honest contributors' inputs. Its authors report an implementation and a simulated Tor measurement application. Those are specific research claims with specific assumptions, not a universal assurance that any consortium's records describe reality. Su and colleagues, SCIF
For the cooperative pilot, an accepted capacity field might be required to lie within an allowed range. That can reject an impossible encoding. It cannot, by itself, establish that a van exists, that its refrigeration works or that the operator has counted tomorrow's commitments correctly. A plausible lie can satisfy a well-designed format constraint.
This suggests separating three checks in the pilot plan. Does the submitted value have the correct representation? Does it satisfy the agreed business definition? Does independent evidence support it? The first may be enforced mechanically. The second requires a shared vocabulary. The third may require an audit or another evidence process outside the private computation.
The distinction is not an argument for copying all underlying records into a central warehouse. It is an argument for deciding which evidence is necessary and where it can be checked. A contributor could attest to an extraction procedure, retain supporting records locally and agree to a narrowly scoped review. Whether that is sufficient depends on the stakes and the incentives.
A finished output should state its input conditions. Readers need to know whether the result describes audited records, contributor-reported figures or a trial dataset. Cryptographic correctness should not become a substitute adjective for data quality.
Queries themselves need permission
A private database system needs rules about more than the contents of a record. It also needs rules about which questions may be asked.
An October 9, 2026 paper by Gu, Li and Shi examines query processing for secret-shared databases when owners may act maliciously. The authors combine verifiable outsourcing, input constraints and query-level governance under an honest-majority assumption. They explicitly distinguish their integration from inventing a new cryptographic primitive. Their reported experiments support an evaluation of that framework, not a claim that an arbitrary organization's authorization problem has been solved. Gu and colleagues, Cybersecurity
The cooperative example makes the issue tangible. A question about demand in a broad delivery district might be approved. A sequence of slightly altered district boundaries could serve another purpose: discovering whether a particular customer is included. The calculation's privacy during execution and the legitimacy of the requested question are different layers of the service.
One practical proposal is a small, explicit query catalogue for the pilot. Each entry describes the purpose, permissible inputs, recipients, frequency and expected action. Changes require a recorded decision. The catalogue is not a universal defense against inference, but it creates an inspectable boundary that an open-ended dashboard would lack.
The project should also decide what happens when a request is rejected. A detailed error message can be useful for debugging but should not casually reveal a contributor's secret value. Operators need enough information to repair faults; result recipients do not necessarily need the same diagnostic view. Separating those audiences should be intentional.
Finally, authorization needs an owner. If everyone assumes somebody else approves new queries, the actual policy may become whatever the most technically capable participant can run. The strongest calculation in the workflow will not repair that organizational vacuum.
The answer can disclose what the process conceals
Prio, presented by Corrigan-Gibbs and Boneh in 2017, is an influential example of private aggregate statistics. Its privacy statement is explicitly qualified by what the computed aggregate itself can reveal. The work also addresses malicious client contributions through a proof technique. A proceedings errata link is available alongside the paper, a reminder to inspect the published record rather than treating a familiar project name as a complete specification. Prio at USENIX NSDI 2017
Here is an original arithmetic illustration, not a measurement from Prio or any deployment. Suppose a published district total is 24 crates. One cooperative already knows that its own contribution was 20 and knows that exactly one other cooperative contributed. The other contribution is four. No secret share needed to leak for that deduction to work.
Changing the released output changes the inference. A simple answer that combined demand exceeds an agreed threshold may reveal less than the exact total, but it still reveals something. Repeating the test at several thresholds can disclose more. Knowing that a route is viable may itself be commercially useful information, which is why the participants wanted the calculation in the first place.
This is the unavoidable design tension: useful results convey information. The goal cannot be to communicate a useful answer while guaranteeing that no recipient learns anything whatsoever. The goal is to identify the intended disclosure, assess the unintended inferences and decide whether the balance is acceptable.
An output review should therefore include a knowledgeable recipient, not just an outsider without context. What can a competitor infer using its own records? What can a local resident infer from public information? Which changes between successive releases would be revealing? Those questions make the privacy assessment harder but more realistic.
The project may decide to combine categories, reduce release frequency, alter the output or use another privacy mechanism. None of those choices should be advertised as automatically safe. Each changes the information provided and the usefulness of the result.
MPC, differential privacy and encrypted computation solve different problems
It is helpful to keep neighboring ideas separate. MPC concerns collaborative computation under a specified security model. Differential privacy concerns a defined statistical relationship between outputs when an individual's contribution changes. Homomorphic encryption allows particular operations to be carried out on encrypted values. A system can combine techniques, but the name of one does not confer the guarantees of another.
A 2015 paper by Kairouz, Oh and Viswanath studies multiparty interactive computation under differential privacy for parties holding private bits. Its particular mathematical setting matters: the stated optimality result should not be generalized into a claim that every real-world collaborative analysis needs the same protocol. The paper illustrates that output privacy and distributed computation can be examined together, rather than assumed to be interchangeable. Secure Multi-party Differential Privacy, NeurIPS 2015
For the delivery pilot, a sensible discussion starts with the harm, not a contest between acronyms. Is the concern that a computing operator will inspect individual records? That a published district result will expose a small contributor? That an outside hosting service will hold a reusable decryption capability? The answers may lead to different architectural requirements.
It is also possible to make the project unnecessarily complicated. If a narrow, consented exchange between two partners already provides the needed result with acceptable exposure, a consortium-wide cryptographic platform may not be justified. Conversely, a conventional access-controlled warehouse may leave a central concentration of data that participants specifically want to avoid.
The editorial recommendation is to compare architectures against the same purpose and failure cases. Do not compare a fully specified conventional service with an idealized cryptographic slogan. Do not compare a carefully analyzed MPC protocol with the worst imaginable conventional database. Each proposal should say what it protects, what it reveals, what it costs and what its operators must do correctly.
Speed is a property of a whole workload
Published demonstrations can show that a useful computation is feasible without establishing that every related workload is practical. CrypTen's research paper, for example, presents a machine-learning-oriented MPC framework, with tensor abstractions and benchmarks under a semi-honest threat model. Its reported speech, text and image tasks are particular experiments. Their results should not be repackaged as an unrestricted promise about all models, networks or adversaries. Knott and colleagues, CrypTen
For a proposed pilot, the performance question should be attached to the action that follows. A route-planning study performed once a month may tolerate a delay that would be unacceptable for dispatching vehicles in real time. An overnight calculation may be useful even if it is nowhere near instantaneous. A very fast calculation may be irrelevant if contributors need weeks to reconcile their records.
The team should define a complete timed exercise: prepare the inputs, validate them, distribute what the protocol requires, execute the calculation, authorize release and interpret the result. Report the stages separately. Otherwise, one organization may describe only the cryptographic kernel while another describes the entire operational process, and the comparison will be misleading.
Use the actual intended scale and network arrangement when possible. A test with every process on one machine answers a different question from a test across independently operated sites. A synthetic dataset can be appropriate for early testing, but it should be labeled and should exercise the shapes and exceptional cases expected in use.
There is no need to invent an impressive benchmark number for a public explanation. A useful report can say what was tested, how long each stage took and what remained untested. The absence of a universal speed claim is a sign of a well-bounded evaluation, not a weakness to hide.
Completion is a separate guarantee
A project can protect information yet fail to deliver a result. The theory of fairness in secure computation addresses whether parties receive their outputs rather than allowing one side to gain an advantage by stopping. Research by Beimel, Omri and Orlov studies partial fairness under particular restrictions and adversarial bounds. Its findings underscore that full fairness is not an automatic consequence of using secure computation. The archive submission is dated 2010; the retrieved PDF has an August 2018 document date, so those dates should not be conflated. Secure Multiparty Computation with Partial Fairness
For our fictional cooperatives, a failed monthly planning calculation might be inconvenient. A failure during an operationally critical decision could have much greater consequences. The acceptable response depends on the use case. That is why a service agreement should discuss noncompletion before the first live round.
What happens if an operator is unavailable? What happens if a contributor submits too late? Does the system restart, omit a contribution under a stated rule or declare the entire round invalid? Can a party learn an output before others do? The implementation's actual guarantees determine which answers are possible; a project manager should not promise them by intuition.
A fallback also needs its own privacy review. An improvised response such as emailing everyone's original spreadsheets to a coordinator can undo the reason for building the system. A safer operational plan is one agreed in advance, with clear limits and explicit consent for any different processing arrangement.
It can be entirely reasonable for a pilot to fail closed and produce no result. That choice trades availability for other priorities. It should be described as a deliberate policy, not concealed behind a claim of uninterrupted service. Participants can then decide whether the task is suitable for the arrangement.
Repetition changes the system being evaluated
A computation rarely lives alone for long. Someone asks for a second district, another month or a new comparison. Separate teams may run related analyses at the same time. A proof about one setting should not be casually treated as a proof about every surrounding workflow.
Lindell's work on composition examines precisely why secure protocols in isolation do not necessarily retain their guarantees in more complex combinations. The author's research page describes results involving different assumptions and models, including a common reference string. The relevant lesson for this article is narrow: composition is an explicit security subject, not a property that should be presumed from a collection of individually reassuring components. On the Composition of Secure Multi-Party Protocols
In the pilot, repetition has both technical and interpretive consequences. The implementers must assess how executions interact. The governance team must assess what a sequence of authorized results allows recipients to learn. These are related concerns, but they are not identical, and neither should be delegated to a slogan about privacy by design.
A release ledger can make the second concern visible. Record which output was released, to whom, for what purpose and in which round. The ledger need not contain the protected inputs. Its purpose is to prevent the organization from forgetting its own disclosures when considering a new request.
A new purpose should trigger a review rather than an automatic extension. Information gathered to explore shared deliveries should not silently become a tool for ranking individual cooperatives or analyzing customer behavior. Even if a new calculation can be executed securely, its legitimacy still requires an argument.
That separation is important for public trust. People may accept a bounded collaboration and object to a broader one. Technical feasibility is not evidence that the original permission covered the expansion.
An original pilot design: seven decisions before implementation
The following seven decisions are an editorial proposal for the fictional delivery consortium. They are not a validated protocol, a compliance checklist or a substitute for specialist review. Their purpose is to show what a substantive project conversation could look like before anyone selects software.
First, define the action. The initial output will identify broad districts worth discussing, not allocate vehicles or expose customer-level demand. This keeps the first experiment attached to a modest decision. If the participants later need scheduling, that becomes a separately specified phase rather than an invisible enlargement of the pilot.
Second, define the unit. A crate, a temperature requirement and a delivery interval need shared meanings. The participants should work through example records together, including an order that is canceled, split across deliveries or already committed elsewhere. Disagreement here can produce an apparently precise result whose terms mean different things to its contributors.
Third, define the roles. Name the data contributors, computing operators, output recipients and people authorized to change the query. Identify affected customers even if they are not direct users. A diagram should reveal where those roles overlap and where an organization has more than one kind of power.
Fourth, define the disclosure. Write down the proposed result and the known information a recipient may combine with it. Test edge cases involving only a few contributors or a dominant contributor. Do not rely on an attractive chart to make a small group look anonymous.
Fifth, define the threat model with the implementer. Record which kinds of deviation, compromise and collusion are covered. Translate at least the most consequential exclusions into sentences understandable to every participating cooperative. If that cannot be done, the project has a communication problem before it has a deployment problem.
Sixth, define the stopping conditions. A failed validation, missing operator or unapproved query should lead to a documented response. Avoid a fallback that expands data access merely because the planned computation is inconvenient. Make clear when no result is preferable to a result obtained through a different, unapproved process.
Seventh, define the evaluation. The pilot succeeds only if the result helps the intended planning decision and the participants can account for the privacy, integrity and operational conditions under which it was produced. Completing a demonstration without a useful outcome is a technical milestone, not necessarily a successful service.
What a public results page should show
A public-facing explanation of this pilot should not begin with an impenetrable protocol name. It should begin with the question answered and the decision it supports. Readers should be able to distinguish the purpose from the mechanism before encountering any equations.
A compact methods panel could state that the work is a pilot, identify the reporting period, describe the contributing population and explain whether the data were synthetic, self-reported or independently checked. Another panel could show the roles without exposing sensitive operational details. The full technical specification should remain available to appropriate reviewers rather than being replaced by the panels.
The visualization should correspond to actual evidence. Before results exist, a diagram may show the flow from contributor inputs through separate computing parties to an approved output. It must be labeled conceptual. It should not include invented percentages, a fake reduction in breaches or an unmeasured speed advantage. Decorative locks are not data.
If results later exist, the chart should make its denominator and exclusions visible. A district omitted because the result was not released should not be colored as if it had zero demand. A failed round should not disappear from an otherwise flattering success timeline. These are editorial choices that affect how honestly the project presents its work.
Accessibility belongs in this explanation. Use words and shapes alongside color. Keep labels legible on a phone. Provide alt text that explains the relationships rather than merely listing colors. A reader who cannot see the arrows should still understand that contributors, computing operators and result recipients have different roles.
The page should end with unresolved questions and the next decision, not a declaration that privacy has been solved. A bounded pilot can be valuable precisely because it reveals where a wider deployment would need additional evidence.
Questions worth asking before signing on
A potential participant can begin with a straightforward request: show me the exact output someone else will receive because I contributed. If the answer is still being designed, participation terms should acknowledge that uncertainty instead of treating consent as an unlimited blank check.
Ask who can change the software or computation specification, and how those changes are reviewed. Ask which operators are genuinely separate and what evidence supports that separation. Ask whether a common administrator, service provider or recovery process can cross the boundaries drawn in the architecture diagram. These questions concern the actual deployment, not the elegance of its mathematical description.
Ask how erroneous inputs are corrected. An ordinary spreadsheet workflow encourages opening a record and editing it. A privacy-preserving process may require a different correction procedure. The project should demonstrate that procedure using non-sensitive test data before discovering its limitations during a consequential live round.
Ask which outputs are retained, which intermediate materials are retained and why. The answer should distinguish practical retention policies from mathematical privacy claims. Avoid promises that deletion can retract facts already learned from a released result. Future use can be restricted by policy, but history cannot simply be made unread.
Ask for a performance report that describes the security model and the complete workload. A bare throughput number has little meaning without those conditions. Ask what tests failed and which configurations were not evaluated. A responsible implementer should be able to discuss those boundaries without interpreting every question as hostility.
Finally, ask what would make the project unnecessary. If the organization cannot imagine a simpler alternative, it may be selling a technology rather than solving a defined problem. A credible proposal should explain why its complexity buys a benefit that matters to these participants and this task.
Test the interpretation as well as the computation
An acceptance exercise can include a deliberately awkward result. For the fictional pilot, prepare a synthetic district in which one contributor supplies almost all the demand, another in which the data are incomplete, and a third in which the calculation is valid but the proposed route is impractical for a reason the model does not represent. These are proposed test scenarios, not evidence that a particular implementation has failed.
Then ask the intended recipients to explain each output in their own words. If they describe incomplete data as low demand, or a successful calculation as a guarantee that a route will work, the presentation needs revision. The misunderstanding is observable without exposing real customer records.
This exercise tests the last handoff in the system: from a formally produced result to a human decision. It should include the people expected to act, rather than only the team that built the interface. Record the explanations that caused confusion and revise the wording before adding more elaborate graphics. A plain statement of what the result excludes can be more useful than a polished display that encourages an unjustified conclusion.
The acceptance record should also identify who is authorized to interpret the result on the consortium's behalf. A communications team may simplify a technical output for members or the public. That translation can introduce a new claim, such as describing possible route compatibility as an agreed delivery service. Have the technical and operational owners inspect the proposed wording together. Keep the approved explanation beside the result so that later presentations do not gradually strengthen the claim through repetition. This is a small administrative step with a concrete purpose: preserving the difference between what was computed and what someone subsequently promised.
A narrower exchange can be a meaningful advance
The strongest case for MPC is not a fantasy of institutions that require no trust, produce no revealing outputs and never make mistakes. It is a more disciplined arrangement in which parties can pursue an agreed result without automatically creating another broadly accessible collection of raw records.
The research record contains deployed applications, theoretical limits, software frameworks and ongoing work on integrity and governance. Those categories should remain visible. A historical auction is evidence of one practical application. A framework benchmark is evidence about tested workloads. A standardization call is evidence of a process. None is a universal warrant for every product description that borrows the vocabulary.
For the fictional cooperatives, the desirable outcome is modest and useful: learn whether a particular collaboration merits the next conversation while revealing less than an indiscriminate data exchange would require. They would still need to agree on definitions, evaluate outputs, choose operators and handle failure. The cryptography changes the options available to them; it does not write their agreement.
That is a substantial public-interest opportunity. Organizations often face a false choice between refusing any collaboration and handing over more information than the task requires. Secure computation can create another option, provided its boundaries are explained honestly and its usefulness is demonstrated rather than assumed.
The first question remains the simplest one: what do we need to learn together? A project that can answer it precisely has a much better chance of deciding what should remain apart.
Evidence and reading notes
Prepared November 1, 2026. The fictional cooperative pilot, arithmetic example, procurement questions and layout proposals are original explanatory analysis, not reported deployments or performance measurements. Source-specific research summaries are intentionally short; no source's whole paper is reproduced. Software documentation is a living source accessed on the preparation date, not a frozen certification.
- NIST IR8214C, January2026: official call, not product approval.
- Bogetoft et al., Secure Multiparty Computation Goes Live: opened13-page author paper; historical January2008 deployment.
- Shamir, 1979: opened2-page foundational paper.
- Lapets et al., COMPASS2018: opened5-page author paper on accessible deployments.
- Keller, MP-SPDZ,2020: opened author abstract and metadata; maintainer documentation also inspected. No detailed benchmark number used.
- SCIF, PoPETs2025: opened abstract and21-page primary paper.
- Gu, Li and Shi, October9,2026: full primary HTML opened; research framework, not deployment certification.
- Prio, NSDI2017: author abstract and proceedings entry opened; detailed performance and corrected equations not relied on.
- Kairouz, Oh and Viswanath,2015: author abstract and9-page primary PDF opened; private-bit setting retained.
- CrypTen,2021/revised2022:23-page primary PDF opened, semi-honest limitation retained.
- Beimel, Omri and Orlov:2010 archive entry and28-page PDF opened; PDF document date2018 noted, no newer empirical finding implied.
- Lindell, composition research: author research summary opened; published monograph2003, not a2026 result.