Design note: confidential computation with verifiable results
Development status: Research — This note records goals, assumptions and open questions; nothing here is an assurance or a released feature. Confidential computation over encrypted data, results others can verify, selective disclosure of results to authorised parties and a managed key lifecycle are design goals being explored. An experimental implementation of encrypted-computation interfaces exists in an internal prototype, but it simulates the behaviour, performs no real encrypted computation and only simulates key handling and the step that would reveal results, so it protects no data; nothing is publicly available for live use.
Before you read: Problem statement and intended properties.
What problem does confidential computation address here, what properties are intended, and what remains unproven? This note gives the research view of confidential computation and the selective disclosure of its results: the motivation, each intended property as a goal, the assumptions those properties would rest on, the limits of what exists today and the open questions. The capability itself, and how it would be used, is described on Confidential computation; this note does not repeat that page and does not describe design detail.
Motivation
Organisations want results from sensitive data without exposing that data more widely than its owner allows. The result might be a figure, a decision or a summary; the records behind it might be commercially or personally sensitive.
Others often need to rely on those results — business partners, customers or the public. Checking a result usually involves seeing the inputs that produced it, which is precisely the exposure the data owner wants to avoid.
On a shared network the difficulty grows. The participants that process work would ordinarily see the data they process. Processing selected data while it remains encrypted is intended to avoid this.
Confidentiality without confidence in the results, or confidence without confidentiality, would not meet the intended uses. This note therefore treats the two together.
Intended properties (each a goal, not an assurance)
Each property carries its own status. None is demonstrated today.
- Processing while encrypted — Being explored. Selected data could be processed while it remains encrypted, so that the participants processing it would not see it. The goal concerns data that an application selects for protection; it does not extend to all information about activity, some of which would remain observable (see the assumptions below).
- Results others can verify — Being explored. Those relying on a result would be able to check it, while who may see the data stays separate from who may rely on the result. How results would be made checkable is not described in this documentation. See verifiable result.
- Selective disclosure of results — Being explored; the reveal step is only simulated. Selected results could be disclosed to authorised parties rather than to everyone. See selective disclosure.
- Managed keys — Being explored; key handling is only simulated. Keys that protect data for confidential computation would follow a managed lifecycle of generation, rotation and revocation.
- Owner control — Being explored. Who could see results would follow the data owner’s visibility choices. See Visibility controls and selective disclosure.
Assumptions the properties would rest on
The properties would hold, if at all, only under assumptions. These are stated qualitatively; none is quantified.
- Keys. Confidentiality would depend on how keys are generated, held, rotated and revoked, and on who holds them. See Key lifecycle: creation, rotation and revocation and Custody options for organisations.
- Who runs the computation. The parties that would process work would be relied on in ways that are not yet described publicly. See Trust assumptions and responsibilities by participant.
- Observers. Some information about activity would remain observable even when contents are protected. See What remains observable.
- Relying parties. What a relying party would have to trust in order to accept a result is not yet specified publicly.
- Recipients. Once a result has been disclosed to someone, they can keep it; a disclosure cannot be undone.
- Techniques. Any technique eventually used would rest on its own cryptographic assumptions, which would be stated with it. No technique is named here.
Limitations, and what the experimental implementation shows
Status of this section: Experimental implementation exists — internal prototype only; it simulates the behaviour and protects no data.
- An experimental implementation of encrypted-computation interfaces exists in an internal prototype. It is a simulation: it imitates the intended behaviour and performs no real encrypted computation.
- Key handling, and the step that would reveal results to authorised parties, are only simulated.
- The prototype therefore protects no data and demonstrates none of the properties above. The full list of simulated features is on Known limitations of the experimental prototype.
- Simulated outputs can look like protected data or checked results; they are not evidence of either.
- The simulation’s speed or cost says nothing about how real confidential computation would perform.
Open questions
- What exactly could be checked about a result, by whom and under which assumptions?
- What would a relying party need to trust, and what could it check for itself?
- How would the cost and speed of confidential computation relate to the protection it provides? The design being explored would meter encrypted computation according to the amount of cryptographic work performed; no figures are published. See Fees and cost estimates.
- How would rotation or revocation of keys affect data and results already protected under earlier keys?
- Who would decide which results are disclosed, to whom and for how long, and how would such decisions be reviewed?
- How would these properties be evaluated, and what evidence would be published? See Evaluation methodology and published results.
These questions also appear in the consolidated list on Assumptions and open questions. No answer is published, and none should be inferred from the way a question is phrased.
How this note relates to other pages
- The capability, its status and how it would be used: Confidential computation.
- Owner-controlled visibility and the disclosure of results: Visibility controls and selective disclosure.
- Long-running confidential work: Confidential jobs: tracking, cancelling and retrieving results.
- The application pattern: Processing sensitive data with verifiable results.
- Behaviour under partial failure: Design note: operating under partial failure and evolving participation.
Assumptions, trust and limitations
- The properties are design-stage goals; they may change, be deferred or be withdrawn.
- Nothing in this note is a confidentiality, correctness or performance assurance, and the experimental prototype provides no confidentiality protection.
Not yet available, and how this page will grow
- Further technical reference is not yet available.
- If reviewed design material is approved for publication, this note would link to it with its date; evaluations would be linked from Evaluation methodology and published results.
- If this note is superseded, it would remain at this address with a “not current” banner linking to its replacement.
What this note does not claim
This note does not claim:
- any technique, construction, parameter or security level;
- any performance or cost figure;
- any comparison with other approaches or platforms;
- any assurance of confidentiality, correctness or availability;
- any confidentiality protection today, or any available feature.
Anything not stated here as available or assured should be treated as neither.
Related pages
- Confidential computation — the capability, its simulated status and how it would be used.
- Visibility controls and selective disclosure — owner-controlled visibility and the disclosure of results.
- Key lifecycle: creation, rotation and revocation — the planned key lifecycle, simulated today for this capability.
- Assumptions and open questions — these questions in the consolidated list.
Glossary
- Confidential computation
- Encrypted data
- Verifiable result
- Relying party
- Selective disclosure
- Key rotation
- Key revocation
- Simulation
References
No approved public references yet.