REFERENCE

EPT Syntax

Engyon Protected Text is a human-editable annotation method that adds cryptographic confidentiality and integrity to any text file.

Overview

EPT directives are embedded in the host language's comment syntax so they don't affect rendering or compilation. An EPT document can contain both public and classified sections, with different access levels for different collaborators.

The core operations are:

• Encrypt / Decrypt — reversible AEAD encryption of named segments ("WORD"s)
• Store / Fetch — content-addressed storage for large or sensitive blocks
• Sign / Verify — digital signatures over content
• Immutable / Mutable — hash-based integrity protection

Separators

EPT statements appear between configurable left and right separators. The defaults are designed to look like comments in C-like languages:

// <( STATEMENT )>

Common separator configurations per host language:

Separators are configurable via -l/--left-separator and -r/--right-separator CLI flags, or the config file.

Directives

The canonical directive vocabulary:

The RSD spec vocabulary (CLASSIFY/UNCLASSIFY/CLASSIFIED/SIGNED/SIGNATURE) is accepted as input-only aliases. The writer always emits the canonical form.

Classified Blocks

A block of text can be marked for confidentiality protection by enclosing it between BEGIN/END statements with a WORD name. The WORD maps to a shared symmetric key.

// <( BEGIN database_url )>
postgres://localhost/myapp
// <( END database_url )>

After encryption, the plaintext is replaced with ciphertext:

// <( ENCRYPTED database_url pbkdf:$argon2id$... cipher:aes-256-siv )>
// <( DATA SGVsbG8gV29ybGQhIFRoaXMgaXMgZW5jcnlwdGVkIGRhdGEu )>
// <( END database_url )>

The pbkdf: and cipher: extfields are self-describing metadata — the encrypted block carries its own key-derivation parameters and cipher algorithm, so no external configuration is needed to decrypt.

Signed Blocks

Blocks that require integrity protection are enclosed in signed scopes. enprot supports Ed25519, ECDSA P-384, RSA, ML-DSA (post-quantum), and OpenPGP signatures via librnp.

// <( BEGIN contract )>
The reward is $3.14 for information leading to the arrest of Bob.
// <( END contract )>
// <( CHAIN signer:abc123 sig:base64... parents:hash1,hash2 )>

Signatures cover the ciphertext representation of all blocks, so they remain valid across classification transitions (classified → unclassified → classified).

Immutable Blocks

Content that must not change can be locked with a hash:

// <( IMMUTABLE license sha3-256=a1b2c3... )>
MIT License — Copyright (c) 2026 Ribose Inc.
// <( MUTABLE license )>

When sanitized, the content is replaced by a MUTED pointer:

// <( MUTED license sha3-256=a1b2c3... )>

This is not cryptographic confidentiality — it's integrity protection against accidental modification. The hash is verified on every parse.

Key Management

Engyon supports a wide spectrum of key management:

• Passphrase-derived — PBKDF2, Argon2, Scrypt via PHC-string format
• Local key files — PEM-encoded private keys
• Hardware — SmartCards, HSMs, TPMs (future)
• Multi-recipient — ML-KEM encapsulation for public-key encryption
• Threshold — k-of-n group signing via Confium (future)

Within the EPT syntax, key scopes are defined with KEY/UNKEY and certificate scopes with CERT/UNCERT:

// <( KEY deputies sha3-256=86716A... )>
  ...content signed under this key...
// <( UNKEY deputies )>

Content-Addressed Storage

Large ciphertext blobs or frequently-referenced content can be stored in a content-addressed store (CAS). The document references them by hash:

// <( STORED database_url ct sha3-256=DC910F5E499F8B... )>

The ct keyword indicates the stored blob is ciphertext. The enprot CLI manages the CAS directory automatically — enprot store writes blobs, enprot fetch retrieves them.

Cryptographic Realization

Engyon adopts a flexible approach to cryptographic algorithms, emphasizing international and national standards:

Symmetric AEAD

• AES-256-SIV (RFC 5297) — default; nonce-misuse resistant
• AES-256-GCM — high-performance hardware-accelerated
• AES-256-GCM-SIV (RFC 8452) — via RustCrypto (Botan doesn't implement)
• Deterministic variants — -det suffix; nonce derived from plaintext via HKDF + HMAC, enabling CAS dedup on encrypted segments

Signatures

• Ed25519 — default; fast, compact, deterministic
• ECDSA P-384 — CNSA suite compliant
• RSA 3072 — legacy compatibility
• ML-DSA-65 (FIPS 204) — post-quantum

Key Derivation

• Argon2id — memory-hard; recommended for passphrase-derived keys
• Scrypt — alternative memory-hard KDF
• PBKDF2-HMAC-SHA-512 — NIST-compatible fallback

Hashing

• SHA-3-256 — default for CAS and integrity
• SHA-3-512 — for signatures

All cryptographic transformations are designed to be deterministic — the same input yields the same ciphertext and the same hash, enabling content-addressed deduplication even on encrypted segments.