Concepts Specifications API Downloads
ConceptsEntrusted actors

Entrusted actors

An actor may entrust other actors. Entrustees have read access to the private data and messages of the actor at any point in time.

Entrusted actors are used when data should remain accessible, but does not need to be actively shared.

An employee may entrust his company, for example. Under normal circumstances, the company does not need to access an employees data directly. Instead, the employee should share with peers or partners whatever is needed through messages. However, there are cases where this does not work. If an employee unexpectedly quits or dies, for example, his data may need to be accessed directly.

For similar reasons, a user may want to entrust a close friend.

In addition, users collaborating on the same project may entrust a third party organization, such as a notary, who could access the data upon presentation of a search warrant.

Private data

When writing a new version of the private data, the actor adds all entrustees as recipients on the envelope. They are not explicitly notified of the change, but can list the actor's private box and decrypt the data at any time.


On message envelopes, entrustees are added as additional recipients, but the message is not placed into their in-queue.

The sender should add both its own entrustees as well as the entrustees of the recipients, which are listed on their public cards.


When necessary, the entrustee accesses the actor's account, and decrypts the private data and message envelopes with its own key.

Offline keys and air-gapped recovery

Private keys of entrusted accounts can be stored offline until the data needs to be accessed. If incidents are rare, the private key may be stored on a piece of paper and/or memory stick in a vault, for example. Data can later be recovered behind an air gap:

Vault Offline system Entrustedprivate key Newpublic key Entrustedprivate key

Offline recovery works as follows:

  1. A temporary offline system is set up. This system only needs a subset of Condensation, namely a record parser and serializer, an object parser and serializer, as well as RSA encryption and decryption.
  2. The original envelope is transferred onto the system.
  3. The user creates a new actor. The public key of the new actor is copied onto the system.
  4. The private key from the vault is entered.
  5. The system then decrypts the AES key from the original envelope, and re-encrypts it for the new actor. The rest of the envelope remains as-is.
  6. The new envelope is retrieved.
  7. The offline system is destroyed.
  8. The new actor signs the new envelope, and attaches it to its private box.

The data itself does not need to be transferred to the offline system.

The offline system may be as simple as a microcontroller. For this very specific application, no full-blown operating system is needed.