Processing sensitive data with verifiable results

Development status: Being explored — The intended pattern is that an application keeps selected data confidential while others can still check its results. An experimental implementation of encrypted-computation interfaces exists internally, but it simulates the behaviour and performs no real encrypted computation, so it provides no confidentiality. How confidentiality and checkability would be achieved is not described. Nothing is publicly available for live use.

Before you read: What Cubane is designed to do.

How would an application keep selected data confidential while others can still check its results? This page describes the intended pattern at the level of outcomes and parties. It states plainly which parts exist only as a simulation in the experimental implementation and why no confidentiality protection is offered today, sets out when the pattern would apply, and points to the open questions recorded on the research pages. It does not describe how confidentiality or checkability would be achieved.

The problem this pattern addresses

Some applications must compute over records that are commercially or personally sensitive — for example, a figure calculated from confidential business records, or a decision based on personal details — while other parties need to rely on the results. Those other parties may be counterparties, reviewers or the application’s own users, and they are often not entitled to see the records themselves.

The usual way to gain confidence in a result is to look at the inputs that produced it: recompute the figure, or inspect the records behind the decision. That conflicts directly with keeping the inputs confidential. The familiar options are uncomfortable: disclose more than the data owner would like, or ask the people who rely on a result to accept it without being able to check it.

This pattern aims to separate the two concerns, so that who may see the data and who may rely on the result can be decided separately. It is the pattern closest to the project’s overall aim, described on What Cubane is designed to do. This documentation does not claim that the tension has been resolved, and it does not describe how the pattern would resolve it.

The intended outcome

Status of this section: Being explored — the design is being explored; its public interface and support are not settled.

• Confidential data, results others can verify. The intended outcome is that an application would keep selected data confidential while producing results others can verify. The data owner would decide which data stays confidential and who can see it. Confidential computation over encrypted data is a design goal; in the experimental implementation it is only simulated.
• Confidential from those who process it. The design goal includes keeping selected data confidential from the network participants that process it. The experimental implementation does not provide this.
• Selected results for authorised parties. Selective disclosure of results to authorised parties is a design goal: a result would go to the parties entitled to it rather than to everyone involved. The step that would reveal results is only simulated in the experimental prototype. See Sharing selected results with auditors and partners.
• Long-running work as confidential jobs. The design being explored includes long-running confidential jobs that could be tracked, cancelled and refunded, with results retrieved later. No job can be run today. See Confidential jobs: tracking, cancelling and retrieving results.

How confidentiality and checkability would be achieved is not described in this documentation. The outcomes above are goals, stated so that you can judge whether the pattern is relevant to you; they do not describe anything that runs.

Who is involved

• Data owner. The party that provides or controls the data, such as an application or an organisation. The data owner would decide who can see which data; see Visibility controls and selective disclosure.
• Application developer. Builds the application that works with confidential data and presents its results to users. The planned developer experience would allow applications to submit confidential jobs and retrieve results through language SDKs; no SDK or developer interface is publicly available.
• Relying party. A person or organisation that depends on a result and needs confidence in it. What a relying party would be able to check, and on what basis, is not described; it is one of the open questions below.
• Participants that would process the work. The network’s participants would carry out the processing. The design being explored includes the use of specialised hardware workers for encrypted computation, which this documentation calls specialised compute workers. No such role is open today, and encrypted computation is only simulated in the experimental implementation; see Participants and roles.

One organisation can hold more than one of these roles. A company might own the data, build the application and rely on the results itself, while an outside reviewer relies on the same results without owning the data. Working out who would hold each role in your own case is a useful first step, and it does not depend on details that are still unsettled.

What exists today

Status of this section: Experimental implementation exists — internal prototype only; simulated, and no data is protected.

• An experimental implementation of encrypted-computation interfaces exists in an internal prototype. It simulates the behaviour and does not perform real encrypted computation.
• Confidentiality and proving features in the prototype are simulated or switched off, so it provides no confidentiality protection.
• No developer interface, SDK or environment exists for building this pattern, and nothing is publicly available for live use.
• Experimental behaviour is not evidence of future confidentiality, correctness or performance. Simulated outputs can look like protected data or like proofs; they are not evidence that anything has been protected or checked.

What the simulation is and is not is described in more detail on Confidential computation and Known limitations of the experimental prototype.

When the pattern would apply

Once the underlying capabilities are implemented, enabled and publicly released, the pattern would be relevant where several of these conditions hold:

• Seeing and relying are held by different parties. Some parties may see the data, while other parties need to rely on results derived from it.
• Selected results, not whole datasets. Specific parties need specific results, not the records behind them.
• Long-running work. Computations are long enough that an application would submit them, track them, perhaps cancel them, and come back later for the result.

Where everyone who relies on a result is also entitled to see the underlying data, the pattern’s intended benefit would be smaller.

Not a fit today. The pattern is not a fit today for any need that requires working confidentiality, or that depends on published performance or cost figures: neither exists.

Open questions

• What could be checked, by whom and under which assumptions. What exactly another party could check about a result, what it would need in order to do so and which assumptions that would rest on are open questions. They are recorded on Assumptions and open questions and on Design note: confidential computation with verifiable results.
• What remains observable. Even if data were processed confidentially, some information about activity would remain observable to others. See What remains observable.
• How cost would be set. The design being explored would meter encrypted computation according to the amount of cryptographic work performed. No units, formulas or prices exist; no fees are charged anywhere today, and encrypted computation is only simulated, so no cost can be observed. See Fees and cost estimates.

Assumptions, trust and limitations

• The intended properties are goals. The experimental implementation simulates encrypted processing and offers no confidentiality.
• Trust assumptions about who would process data and who would hold the relevant keys are not yet specified publicly; Trust assumptions and responsibilities by participant describes trust in qualitative terms.
• Some information about activity would remain observable even with confidential processing.
• Statements on this page describe either a goal or the current state of the prototype; none is an assurance.

Not yet available, and how this page will grow

Further technical reference is not yet available. Once the underlying capabilities are released, this page would link to versioned reference for confidential computation and for submitting jobs, state the documented assumptions, and add labelled illustrative examples where they help. Approved public references would be listed once approved; none are listed yet.

What this page does not claim

This page does not claim:

• that any data is encrypted or protected today;
• that any result can be checked today, or how any result would be checked;
• that any particular technique is used;
• any performance, capacity or cost figure.

Anything not stated here as available should be treated as unavailable.

Related pages

• Confidential computation — the capability this pattern rests on, and its simulation status.
• Confidential jobs: tracking, cancelling and retrieving results — how long-running confidential work would be handled.
• Privacy and confidentiality: intent and current limits — what confidentiality is intended to mean, and what is protected today.
• Known limitations of the experimental prototype — the full list of current limits.
• Design note: confidential computation with verifiable results — goals, assumptions and open questions for researchers.
• What remains observable — information that would stay visible even with confidential processing.
• Sharing selected results with auditors and partners — disclosing selected results to authorised parties.

Glossary

• Confidential computation
• Verifiable result
• Confidential job
• Data owner
• Relying party
• Selective disclosure
• Simulation

References

No approved public references yet.