RSD 12001 — Edition 1 — Draft

Secure Document — Engyon — Plain Text Representation

Ribose Standard

Introduction

Ribose has developed a document model that supports localization and change sets (collaborative editing). This model relies on the bibliographic data model Relaton and builds on BasicDoc — a hierarchical data model for textual documents.

The Engyon Secure Document Model is designed to achieve:

• A static file result — similar to a Word document, but transmissible via email
• Protection of content and metadata (confidentiality, integrity, authenticity)
• Partial authenticity and encryption — a document may contain both public and classified sections
• Information classification and labelling
• Secure change set features — encrypted sharing and patching
• A text-based workflow — useful in text editors, not requiring specific software

Scope

This document defines a textual representation of the Engyon secure document model. It specifies the syntax for embedding cryptographic confidentiality and integrity features into plain text files.

Terms and Definitions

Secure document

A document protected against unauthorized access.

Semi-honest

Honest in performing operations, but curious and may try to steal data.

User

A person who utilizes a service.

Access control

Mechanisms that restrict access to resources based on identity and authorization.

Author

A person who creates or modifies document content.

Role

A set of permissions assigned to a user within an access control system.

Engyon Protected Text

Engyon Protected Text (EPT) is a human-editable annotation method that allows a text-format document to contain finely grained cryptographic confidentiality and integrity features. It allows parties with different access parameters (e.g. clearance) to collaboratively work on the same document.

EPT annotation is contained in comments so that it does not affect rendering or compilation of the document.

• Classified sections are encrypted with an AEAD algorithm when the document is in unclassified state.
• Signed sections are protected by a signature and can't be modified without detection.

An initial non-integrated version of Engyon "protect" tools takes the form of a single-pass parser that allows text-format documents to be reversibly transformed between different classification levels. The same tool can verify and create signatures inside the document.

In practice, this allows a (partly or wholly) unclassified version of a document to be automatically created where restricted parts are replaced with invisible references (or full encrypted blocks) for distribution. Conversely, one can reclassify a modified unclassified document, making confidential parts available and editable again. Signatures are verified and updated with the same tool.

EPT Statements

An EPT statement is enclosed by a left separator LEFT_SEP and right separatorRIGHT_SEP:

  <( STATEMENT )>

The annotation uses the comment feature of the host language. Common configurations:

The separators are configurable and determined from file type (extension) if available. Statements define blocks of text (such as a confidential or signed part). Blocks can include other blocks for multi-level access control and/or integrity protection.

Immutable Blocks and Binary Blobs

EPT supports Content Addressed Storage (CAS) to abbreviate documents for editing and transmission. CAS allows non-changing parts to be referred by their contents. All references within an EPT document are fully unambiguous — the reference alone fully specifies what is being referenced.

A helper notation for integrity protection:

// <( IMMUTABLE Approved-May sha384=DC910F5E499F... )>
(c) 2026 Ribose Inc. Any trade name used in this document...
// <( MUTABLE Approved-May )>

When muted:

// <( MUTED Approved-May sha384=DC910F5E499F... )>

Group Keys

Engyon supports simple and advanced key management: passphrase-derived keys, local key files, SmartCards/HSMs, online key servers, timed declassification, and k-of-n group control.

// <( SIGNED ... )>
// <( KEY Deputies sha384=86716A025E4AAF0347C9... )>
// <( CERT Alice sha384=7725AD485A8EBDE97BB04E86C1... )>
  .. document body ..
// <( UNKEY Deputies )>
// <( SIGNATURE ... )>

Classified Blocks

A block of text can be marked as needing confidentiality protection by enclosing it between CLASSIFY and UNCLASSIFY (BEGIN/END) statements:

// <( CLASSIFY Deputies aes256siv )>
Confidential Source 13 is Mallory.
// <( UNCLASSIFY Deputies )>

After encryption, the plaintext is replaced:

// <( CLASSIFIED Deputies aes256siv:base64=0mlH0RxyPOf8b1r.. )>

Signed (Integrity-Protected) Blocks

// <( SIGNED Alice ecdsap384 )>
A reward of $3.14 is offered for information leading to arrest of Bob.
// <( SIGNATURE Alice ecdsap384:base64=fI3m+vgcovG1Olu31WPVyh.. )>

Signature blocks can be inside or outside classified blocks, allowing classified signatures and verification of mixed unclassified/classified data.

Cryptographic Realization

The cryptographic core uses international and national standard algorithms. A baseline set consists of AES-256, SHA2-384, ECDSA P-384, and RSA with 3072-bit key — corresponding to CNSA suite requirements for TOP SECRET classification.

Symmetric Authenticated Encryption

A nonce-reuse/misuse resistant AEAD mechanism is used (AES-256 in SIV mode, RFC 5297). SIV ciphertext is always 16 bytes larger than plaintext; the authentication tag serves as the synthetic IV.

Signatures

A deterministic signature function is used (deterministic ECDSA, RFC 6979) so that matching signatures are always generated if the text is unmodified.