Cryptographic foundations and trust roots
Development status: Experimental implementation exists — An experimental implementation exists; this page describes the intended public developer capability. In an internal prototype, core hashing and digital-signature operations rely on established, library-backed algorithms, while certificate-based trust in validators and optional hardware attestation are being explored and policy-governed key handling with hardware-backed custody is planned and not implemented. No cryptographic review results are published, and nothing is publicly available for live use.
Before you read: Security model, trust and limitations.
Which kinds of cryptography does Cubane rely on, and how is trust in validators intended to be established? This page explains, by category, the cryptography the experimental implementation relies on, introduces trust roots, describes the approaches to trusting validators that are being explored and points to the pages on keys and custody. It names categories, not specific algorithms or constructions, and it is explicit about what it does not cover.
What these foundations provide
Three building blocks underpin most of what a network like this would need to check:
- Digital signatures let others check that a message was authorised by the holder of a particular key and has not been altered.
- Hashing produces a compact fingerprint of data, so that any change to the data can be detected.
- A trust root is the starting point that must be trusted without further proof, so that other things can be checked against it.
Together, they let participants check who authorised something, whether it has changed since, and what they are ultimately trusting when they accept it. This page describes kinds of cryptography, not specific algorithms.
Signatures and hashing
Status of this section: Experimental implementation exists — internal prototype only; no review results are published.
- Core hashing and digital-signature operations in the experimental implementation rely on established, library-backed algorithms.
- This does not mean that every cryptographic component is standard, or that any has been independently reviewed. No review results are published.
- No compatibility with the signing or hashing conventions of other systems is implied.
- How recorded state is committed and checked is described on Committed state and inclusion proofs.
- Algorithm names, key sizes, parameters and libraries are not described.
If you are preparing tools or wallets, do not design around assumptions about specific algorithms or formats. None is documented, and they may change before any release.
Trust roots for validators
Status of this section: Being explored — not implemented.
Certificate-based trust in validators is being explored. In general terms, a certificate is a signed statement that binds a key to a participant, so that others can check it against a trust root. The purpose would be to let participants check that a key presented by a validator belongs to that validator, rather than taking it on trust.
- Who would issue certificates, how issuance would be governed and how trust would be withdrawn are not described.
- Certificate-based trust in validators is not implemented.
Tamper-evident logging is covered separately on Audit trails and tamper-evident logging.
Optional hardware attestation
Status of this section: Being explored — not implemented.
- Hardware attestation is a way for specialised hardware to vouch for the software it is running.
- In the design being explored, it would be optional rather than required.
- Using it would add reliance on the hardware, its maker and whoever operates it, rather than remove the need for trust.
- Which hardware, vendors or attestation methods would be supported is not described, and hardware attestation is not implemented.
Keys and their lifecycle
Status of this section: Planned — not implemented.
- Cryptographic keys would be created, rotated and revoked under policy, with hardware-backed custody; this is not implemented. See Key lifecycle: creation, rotation and revocation.
- Key handling in experimental software, including the experimental wallet prototype for local testing, must not be relied on for security. See Wallets and the experimental wallet prototype.
- Custody choices for organisations are described on Custody options for organisations.
What this page does not cover
- Other cryptographic techniques that the confidentiality and verification goals would require are not described on this page. Their status is summarised on Privacy and confidentiality: intent and current limits and on Known limitations of the experimental prototype.
- How messages are kept to their intended context is covered on Request abuse and replay protection.
- No algorithm names, key sizes, parameters, constructions or libraries are given on this page.
Assumptions, trust and limitations
- Established algorithms are only as reliable as their implementation, their use and the handling of their keys. No review results for any of these are published.
- Certificate-based trust, hardware attestation and hardware-backed custody would each introduce parties that must be trusted. These trust assumptions are not yet described in detail; see Trust assumptions and responsibilities by participant.
Not yet available, and how this page will grow
Further technical reference is not yet available. If specific algorithms are documented, they would be listed here together with the software version they apply to. Once trust-root arrangements are specified and approved, this page would describe them at capability level and link to versioned reference material. Changes would be recorded in the Documentation change log.
What this page does not claim
This page does not claim:
- that cryptographic components are standard, reviewed or free of weaknesses;
- that certificate-based trust or hardware attestation is in operation;
- compatibility with other systems.
Anything not stated here as available or assured should be treated as neither.
Related pages
- Committed state and inclusion proofs — how recorded state is committed and checked.
- Key lifecycle: creation, rotation and revocation — the planned key lifecycle with hardware-backed custody.
- Trust assumptions and responsibilities by participant — what each participant would rely on.
- Request abuse and replay protection — keeping messages to their intended context.
- Audit trails and tamper-evident logging — tamper-evident records in general.
- Privacy and confidentiality: intent and current limits — the status of confidentiality features.
Glossary
- Digital signature
- Hash
- Trust root
- Certificate
- Hardware attestation
- Key custody
- Hardware-backed custody
- Tamper-evident log
References
No approved public references yet.
