Security model, trust and limitations
Development status: Overview — An experimental implementation exists for internal development only; in it, confidentiality and proving features are simulated or switched off and finality is not connected, so it provides no confidentiality protection and must not be relied on for security. Intended defences against misbehaving participants are being explored and none is implemented; no independent audit results or resilience measurements are published, and a route for reporting security problems has not yet been announced. Nothing is publicly available for live use.
Before you read: System model: how Cubane is intended to work for its users.
What is protected, what is visible, whom must I trust, and what are the known limitations? This page answers each part of that question in a fixed order: what is protected, what is visible, whom you would rely on, what the known limitations are, and where assurance and reporting stand. For each part it gives a short answer for today and for the intended design, each with its own label, and then points to the page in this section that answers it in depth. Internal analyses and parameters are not described.
The short answer
- Today, nothing should be relied on for security. The experimental implementation is internal, is not a release and provides no confidentiality protection.
- The intended design includes confidential computation over encrypted data, layered defences against misbehaving participants and protections for the network’s interfaces. These are design goals, not assurances.
- No independent audit results or resilience measurements are published.
Table: security at a glance — today compared with the intended design, and the page that covers each part.
| Part | Today | Intended design | Covered on |
|---|---|---|---|
| What is protected | Established, library-backed hashing and digital signatures, and per-caller rate limiting with basic request-replay checks, in an internal prototype. Data confidentiality is not protected. | Confidential computation, layered defences against misbehaviour, messages kept to their intended context and time window, certificate-based trust in validators and authentication for interfaces — each being explored or planned | Cryptographic foundations and trust roots; Threat model and misbehaviour defences |
| What is visible | Everything the experimental implementation holds, to whoever runs it | Some protocol metadata expected to remain observable; ways to bound it being explored; no bound published | What remains observable |
| Whom you would rely on | Whoever runs the experimental implementation | Different participants relied on for different things, described in qualitative terms only | Trust assumptions and responsibilities by participant |
| Known limitations | Simulated confidentiality and proving; finality not connected; crash safety not established; no access-controlled data or encrypted-data availability | A limitation would be removed from the list only with evidence of implementation and release | Known limitations of the experimental prototype |
| Assurance and reporting | No independent audit results or resilience measurements published; no reporting route announced | Security-review, resilience and recovery activities planned or at an early preparation stage | Security assurance status and reporting problems |
What is protected
Today — Experimental implementation exists, internal prototype only:
- Core hashing and digital-signature operations in the experimental implementation rely on established, library-backed cryptographic components. This statement covers those operations only. See Cryptographic foundations and trust roots.
- The experimental node’s request interface applies per-caller rate limiting and basic request-replay checks. It must not be treated as authenticated; authentication is planned. See Request abuse and replay protection.
Not protected today: data confidentiality. Encrypted-computation interfaces exist only as a simulation that performs no real encrypted computation, and proving features are simulated or switched off. See Confidential computation.
Intended — Being explored or Planned:
- Confidential computation over encrypted data — Being explored, as a design goal.
- Layered defences against validator collusion and misbehaviour — Being explored; none is implemented. See Threat model and misbehaviour defences.
- Protocol messages kept to their intended context and time window — Being explored. See Request abuse and replay protection.
- Certificate-based trust in validators, with hardware attestation as an optional addition — Being explored; not implemented. See Cryptographic foundations and trust roots.
- Authentication for interfaces — Planned. See Request abuse and replay protection.
Each intended protection is described on its own page with its own label. None is an assurance.
What is visible
- Today: nothing is confidential in the experimental implementation, so all data it holds is visible to whoever runs it.
- Intended — Being explored: even with confidential execution, some protocol metadata is expected to remain observable, and ways to bound and reduce it are being explored. See What remains observable.
- No bound on observable information is published.
- What a particular party could see depends on its role; see Trust assumptions and responsibilities by participant.
Whom you would rely on
Every system asks its users to rely on someone or something. This section names who, rather than claiming that no trust is needed.
- Today: everything rests on whoever runs the experimental implementation.
- Intended — Being explored: application developers, organisations, node operators, validators, key holders and governance participants would each be relied on for different things. Trust assumptions and responsibilities by participant gives the view for each.
- No numbers: quantitative trust assumptions, such as how much misbehaviour the design would tolerate, are not published. Assumptions that are common on other networks should not be assumed to apply.
- Your responsibility today is practical: use only synthetic data and test keys with any experimental software.
Known limitations
These are the main items from the primary list:
- Confidentiality and proving features are simulated or switched off; there is no confidentiality protection.
- Finality is not connected: an experimental status query reports nothing as final.
- Crash safety of saved node state has not been established.
- No access-controlled data and no encrypted-data availability are provided.
- No independent audit results are published.
The complete, dated list is on Known limitations of the experimental prototype.
Assurance and reporting
- No independent audit results or resilience measurements are published. Security-review, resilience and recovery activities are planned or at an early preparation stage.
- Statements elsewhere in this documentation about security properties describe goals, unless a published assurance result is linked beside them.
- A route for reporting security problems has not yet been announced. Once decided, it would be published on Security assurance status and reporting problems and recorded in the Documentation change log.
- Until a route is announced, avoid publishing details of a suspected security problem.
Pages in this section
Each page answers one question:
- Trust assumptions and responsibilities by participant — what each participant would rely on others for, and what remains yours today.
- Known limitations of the experimental prototype — what is simulated, inactive or unproven.
- Threat model and misbehaviour defences — the kinds of misbehaviour the design is meant to resist, and the intended layered defences.
- Cryptographic foundations and trust roots — the kinds of cryptography relied on, and how trust in validators is intended to be established.
- Request abuse and replay protection — rate limiting, replay checks and planned authentication.
- Security assurance status and reporting problems — published assurance (none yet) and the reporting route (not yet announced).
Suggested reading orders:
- Researchers: trust assumptions, then known limitations, then the threat model, then cryptographic foundations.
- Developers preparing applications, tools or wallets: known limitations, then trust assumptions, then request abuse and replay protection.
- Assurance readers, such as auditors and regulators: known limitations, then security assurance status.
Assumptions, trust and limitations
- Security statements describe the state of development as of this page’s date; they are not commitments.
- Experimental behaviour is not evidence of future security, confidentiality or availability.
- This section names categories only. No internal analyses, parameters or test results are published.
Not yet available, and how this page will grow
Further technical reference is not yet available. Once assurance results are approved for publication, the at-a-glance table would link them with their scope and date. When a reporting route is decided, this page would link to it. Status changes in this section would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- any security, confidentiality or availability assurance;
- any audit, certification or security sign-off;
- any quantitative trust assumption;
- trust-free operation.
Anything not stated here as available or assured should be treated as neither.
Related pages
- Trust assumptions and responsibilities by participant — the per-participant view of trust and today’s responsibilities.
- Known limitations of the experimental prototype — the complete limitations list.
- Threat model and misbehaviour defences — the intended defence categories.
- Cryptographic foundations and trust roots — kinds of cryptography and intended trust roots.
- Security assurance status and reporting problems — published assurance and the reporting route.
- What remains observable — information expected to stay visible even with confidentiality features.
- Development status: what exists today and what does not — the status hub for the whole documentation.
Glossary
- Security model
- Trust assumption
- Experimental implementation
- Confidentiality
- Observable metadata
- Threat model
- Independent audit
References
No approved public references yet.
