The phrase “useful data without exposing the data” has moved from cryptographic research papers toward the beginning of deployment discussions.
That is the significance of the National Institute of Standards and Technology’s Workshop on Privacy-Enhancing Cryptography, which begins October 26 and runs through October 28, 2026. The virtual workshop brings together work on fully homomorphic encryption, private-set intersection, zero-knowledge proofs and privacy-preserving digital credentials.
The mathematics is real. The systems are not magic.
Privacy-enhancing cryptography can reduce the amount of raw information organizations exchange. It cannot make information disappear, guarantee that an answer is fair or prevent every inference from the result. The practical question is not whether data are encrypted. It is what the system reveals when it is used repeatedly, at scale and under imperfect conditions.
What these systems actually do
Fully homomorphic encryption, or FHE, allows a party to perform defined computations on encrypted data without possessing the key needed to read the underlying information. As NIST explains, FHE can support arbitrary computations over encrypted data, although different schemes are optimized for different kinds of operations.
A hospital, for example, might send encrypted information to an outside computing service for a specified calculation without giving that service direct access to patient records. The service would process ciphertext and return an encrypted result for an authorized party to decrypt.
That arrangement still leaves several engineering decisions unresolved. Who controls the key? What calculations are permitted? How can the customer verify that the intended code was run? Does the answer itself reveal sensitive information? How much time and computing capacity does the encrypted operation require?
FHE is therefore not one product with one predictable cost. It is a collection of technical approaches with different performance, security and implementation tradeoffs.
Private-set intersection is more limited and easier to describe. Two or more parties compare private lists to identify common elements without revealing the elements that do not match. NIST identifies possible uses including contact discovery and detecting duplicate benefit claims between administrative organizations.
But the result still matters. A system that returns the number of matches may reveal something about a group’s composition. Repeated queries may expose more than one query would reveal. NIST’s workshop materials identify cardinality leakage, repeatability, authorization, verifiability, updatability and collusion assumptions as practical issues in outsourced private-set-intersection systems.
That list is more important than the usual privacy slogan. It shows that protecting the original lists is only one part of the problem.
Zero-knowledge proofs address a different need. They allow one party to prove that a statement is true without revealing the underlying secret. A person could prove possession of a qualifying credential, or prove that an attribute satisfies a requirement, without disclosing every fact contained in the credential. NIST describes zero-knowledge proofs as a way to establish that a statement is true without revealing the information used to support it.
Digital credentials could use that principle to support minimum-disclosure transactions. A retailer might need to know only whether a customer is over 21, not the customer’s full birth date. A government service might need to verify eligibility without receiving a complete identity record.
That does not eliminate infrastructure. Credentials still require issuers, wallets, presentation protocols, revocation procedures and mechanisms to prevent replay or misuse.
Privacy protects a specific information flow
The phrase “the data remains private” is incomplete because privacy-enhancing cryptography usually protects inputs more strongly than it protects the entire system.
A hospital consortium might prevent members from exchanging complete patient records while still revealing that a particular person appears in another institution’s dataset. A benefits agency might compare records without building one central database while still exposing that an overlap exists. A digital credential might conceal a birth date while allowing a verifier to observe that the same credential is being presented repeatedly.
Other information may remain visible:
- the fact that a query was made;
- the timing and frequency of queries;
- the size or structure of a dataset;
- the number of matches;
- credential issuance or revocation;
- failed proofs and error conditions;
- the identity of the requesting organization; and
- the behavior of the system under repeated use.
None of this makes the technology pointless. It makes the security claim narrower and more useful. A system should specify which information is protected, which information remains observable and what an authorized party could infer over time.
The most important question for a deployment review may be simple: What new information becomes visible when the system is used repeatedly and at scale?
New cryptography creates new dependencies
Privacy-preserving systems distribute control among more parties than a conventional database might. Responsibility may be divided among the organization holding the source data, the party controlling the cryptographic keys, the developer defining the computation, the cloud provider performing it, the credential issuer, the wallet provider and the organization interpreting the result.
That division can reduce the need to create one large pool of sensitive information. It can also make failures harder to assign.
If a private computation produces an incorrect benefits match, who is responsible? The source data may have been wrong. The computation may have been implemented incorrectly. The key-management system may have failed. The verifier may have applied a valid proof to an inappropriate decision rule. A cloud provider may have executed the wrong function without being able to see the underlying data.
Cryptography can protect a computation. It cannot make bad data accurate, make an unfair eligibility rule fair or establish that an institution will respond competently when the system fails.
Digital credentials present the same tension. NIST’s work on credential presentation describes challenges involving wallets, interoperability, online and in-person presentation, revocation and availability. A credential may disclose less information than a scanned identity document while making the user more dependent on an issuer, wallet, status service or device.
That is not necessarily a reason to reject digital credentials. It is a reason to treat them as identity infrastructure rather than as a convenient replacement for a plastic card.
Who benefits, and who carries the risk?
Potential beneficiaries include patients whose records can be used for limited research without broad disclosure, agencies that need to compare records without creating a national database, companies seeking fraud signals without exchanging complete customer files and people who need to prove age or eligibility without exposing unrelated personal information.
Researchers may also benefit when privacy restrictions prevent organizations from pooling sensitive data directly. In that setting, cryptographic tools can make a previously impossible or politically unacceptable collaboration technically feasible.
The risks will not be distributed evenly.
People may be unable to understand or challenge an automated result. Smaller organizations may lack the expertise to audit an implementation. A vendor may control the software while the customer remains responsible for the consequences. A credential wallet or status service may become unavailable at the exact moment a person needs to access housing, employment, health care or government assistance.
There is also a risk of privacy theater by mathematics: deploying an advanced cryptographic protocol while retaining weak access controls, poor key management, inaccurate records or opaque decision rules.
A mathematically sophisticated system can still produce an administratively unfair outcome.
The deployment questions matter more than the demonstration
NIST’s workshop is evidence of a field trying to move from abstract promise toward benchmarks, protocols, use cases and standards. It is not a certification that these methods are ready to replace ordinary databases or identity systems.
For every deployment claim, organizations and reporters should ask:
- What data are protected?
- What does each participant learn from the output?
- What metadata remain visible?
- Can the same query be repeated?
- Who controls the keys?
- What happens if parties collude?
- How is correctness verified?
- How quickly can a credential or key be revoked?
- What happens when the wallet, proof service or key system is offline?
- Can an affected person challenge the result?
- What are the measured latency, storage and operating costs?
- Has the system been tested outside the developer’s control?
Those are not secondary compliance questions. They determine whether privacy protection survives contact with ordinary institutions.
The technology may eventually support health-data matching, benefits administration, fraud detection, age verification, professional licensing and cloud computation. But a laboratory demonstration is not a patient-care system, a deployed benefits decision or a functioning identity network.
Privacy is becoming an engineering discipline
The important change is not that privacy-enhancing cryptography has solved privacy. It has made privacy more explicitly a systems-engineering problem.
Organizations now have tools that can limit what other parties see while still allowing computation, verification or comparison. That is valuable. It may reduce unnecessary copies of sensitive information and make carefully bounded collaboration possible.
But the protection applies to particular information flows, not automatically to the whole system or to the people affected by its decisions. Keys, outputs, metadata, authorization, revocation, availability, auditability and recovery still matter.
The strongest privacy-preserving system will not be the one with the most impressive cryptographic vocabulary. It will be the one ordinary institutions can deploy, inspect and recover without requiring users to trust another invisible layer.
