> For the complete documentation index, see [llms.txt](https://cifer.gitbook.io/cifer-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cifer.gitbook.io/cifer-docs/network-whitepaper/key-custody-and-the-blackbox.md).

# Key custody and the Blackbox

Traditional key-management systems can concentrate risk in a master key, administrator account, or central hardware module. Cifer uses distributed custody to remove that single point of cryptographic failure.

### 3-of-5 custody

{% stepper %}
{% step %}

### Generate

Key material is created inside a hardware-isolated environment.
{% endstep %}

{% step %}

### Split

The private decryption capability is divided into five threshold fragments.
{% endstep %}

{% step %}

### Distribute

Each fragment is assigned to an independent custody node. No custody node stores a complete key.
{% endstep %}

{% step %}

### Authorize

Before fragments are released, the system verifies cryptographic identity, current authorization state, request freshness, and node policy.
{% endstep %}

{% step %}

### Reconstruct and clear

At least three fragments are reconstructed temporarily inside the Blackbox for the authorized operation. Sensitive working material must then be cleared.
{% endstep %}
{% endstepper %}

### Security and availability balance

* One or two unavailable nodes do not block an authorized operation.
* Compromise of one or two nodes does not provide enough fragments to reconstruct a key.
* A coordinated compromise of three or more relevant nodes is a threshold-level incident and must be treated as a critical security scenario.

### No master key

Cifer does not use one global key capable of decrypting every user's data. Each protected secret or user context is isolated under its own cryptographic material.

The statement “no master key” must not be misread as “keys never exist in memory.” An authorized decryption operation necessarily uses working key material temporarily. The security objective is that complete private keys are not stored at rest in one place and are reconstructed only within the controlled execution boundary.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://cifer.gitbook.io/cifer-docs/network-whitepaper/key-custody-and-the-blackbox.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.