Encryption Method

Table of Contents

Learn the OmegaSafe encryption method and a system that implements it.

This page documents the OmegaSafe encryption method, architecture of a system that implements it and the encrypted-file format.

This method is formally described in:

UK Patent Publication: GB2637041
Application Number: GB2400210.7
Title: Method and System for Non-Algorithmic Encryption
US Patent Application No.: 19/694,722 was filed as well.

The implementation here follows the concepts disclosed in the patent publication, providing practical software for this new encryption paradigm.

1. ‘Byte Replacement Map’ Model
#

At the core of the OmegaSafe encryption is the concept of a Byte Replacement Map — a fixed permutation of all 256 byte values (0–255). The permutation is generated randomly by a cryptographically safe library.

The map is essentially a substitution table. For any given input byte x, the map returns a single output byte map[x]. Input byte is used as an index into the map, which returns the corresponding output byte.

Byte Replacement Map Chain: is a sequence of indexed Byte Replacement Maps stored back-to-back.

Nucleus: The key’s primary component is the Nucleus, which is the first Byte Replacement Map Chain used for encryption.

Rotors: In addition to the Nucleus, the encryption key includes one or more Rotors (3 by default), which are additional Byte Replacement Map Chains.

Per-byte encryption flow: Each plaintext byte is substituted by passing through the Nucleus map and then each Rotor’s map in sequence. That combination of Byte Replacement Maps is never reused. Only one plaintext byte globally is converted using that combination.

Map rotation mechanics: The selected replacement map from the Nucleus changes for every byte. Once the Nucleus completes a full cycle, the first Rotor advances by one map. When the first Rotor reaches its end, the second Rotor advances by one map, and so on — like an odometer. Using multiple Rotors exponentially expands the key space: if the Nucleus has N maps and there are two Rotors with R1 and R2 maps respectively, the total number of unique map combinations is N × R1 × R2.

2. Global Positions and Key-Space
#

The system assigns each possible map-combination a sequential index called a global position. Global positions are scoped per key (key_uuid) and shared across all iterations of that key, ensuring no map combination is ever reused regardless of which key iteration performs the encryption.

Position calculation: OmegaSafe CLI calculates map indices directly from the global position and key properties using modular arithmetic. Rotations are not simulated.

Key-space size examples: The Cartesian-product structure of the key yields an enormous key space while keeping cryptographic operations fast. For example, a 4 MB key containing a 1 MB Nucleus and three 1 MB Rotors can encrypt 232 TB of data. To encrypt the entire world’s internet data (estimated at 181 ZB for 2025) with one Nucleus and three Rotors each of the same size, a key of approximately 668 MB would be required (about 167 MB per component, i.e. 652,343 full 256-byte replacement maps per component; 652,343⁴ ≈ 181.09 ZB) — a key that would fit on an old-school CD.

OmegaSafe CLI coordinates global-position usage through External Claims Storage (ECS) so that map combinations are never reused across devices and users. Thanks to eager and proactive caching, the CLI connects to ECS rarely and can safely operate during prolonged periods of no connectivity. For the External Claims Storage backend overview and setup paths, see Encryption Method — External Claims Storage.

3. Alpha and Delta Split
#

OmegaSafe keys are iterative:

The first iteration is the Alpha (seq_number = 0).
Subsequent iterations are Deltas (seq_number > 0).

Security rules governing the split:

Alpha key material is never distributed by ECS. ECS stores key metadata and encrypted Delta payloads.
Deltas are encrypted by Alpha before upload.
Deltas are shared automatically between users and devices that possess the relevant Alpha.
Deltas are not usable without the matching Alpha.
In the OmegaSafe CLI flow, Alpha claim space is reserved for Delta lifecycle operations (new Delta encryption and pulled-Delta decryption), while payload encryption and decryption use Delta iterations.

For multi-device or multi-user setup, export Alpha with export-key, transfer it by your approved secure process, and import it on the receiving side with import-key. Keep Alpha transfer separate from Delta-access channels and do not transport them together.

Never share ECS credentials with other users — grant key access in ECS using the invitation flow described in Keys Management — Key Sharing Model instead. There is no extra cost to that but you get control over permissions and access, and avoid leaking credentials during handover.

4. Decryption Flow
#

Decryption reverses the encryption process: each ciphertext byte is traced backward through the same maps (last Rotor to Nucleus) using reverse lookup.

Using encryption metadata for accuracy: Each encrypted file stores encryption metadata containing the key_uuid and the global_position_start. This encryption metadata is unencrypted by default, but it can be encrypted by the traditional encryption layer; see Encryption Method — Optional Traditional Encryption Layer. During decryption, OmegaSafe CLI uses these two values to reconstruct exactly which map combination was applied to the first byte of the file. The remainder of the required global positions is derived from the plaintext size, which is stored in the encrypted file metadata prefix. This means the decryptor can deterministically reproduce every map combination used during encryption without any additional information.

Integrity verification: The encrypted file metadata also stores a SHA-256 hash of the original plaintext. After decryption, OmegaSafe CLI verifies the decrypted output against this hash to confirm the encrypted file was not tampered with.

5. Encrypted File Format
#

The default output filename is a random UUID with the .omegasafe extension, but neither the file name nor its extension affect decryption. Files can be renamed after creation or given a custom name at creation time with --file-name-override. The extension is not part of the cryptographic validation.

Encrypted file structure
#

Each OmegaSafe encrypted file has the following structure:

flowchart TD
    SFC["SecureFileContainer
(native file format)"]
    SFC --> META["ENCRYPTION_METADATA_UUID
encryption metadata"]
    SFC --> DATA["ENCRYPTED_DATA_UUID
encrypted data"]
    DATA --> FILEMETA["encrypted file metadata
(1024-byte prefix)"]
    DATA --> FILE["encrypted file"]
    DATA --> SUFFIX["random suffix
(0-5% plaintext size)"]

OmegaSafe CLI extracts the two top-level container entries by their static UUIDs: ENCRYPTION_METADATA_UUID and ENCRYPTED_DATA_UUID.

Outer Structure: SecureFileContainer
#

An encrypted output file is itself a SecureFileContainer with two internal entries:

ENCRYPTED_DATA_UUID — the encrypted_data payload
ENCRYPTION_METADATA_UUID — the encryption metadata payload (encryption_metadata.json)

For the broader role of this container format across OmegaSafe, see Encryption Method — Secure File Container.

Encryption Metadata
#

encryption_metadata.json is the encryption metadata payload. It contains only the minimum information required to start OmegaSafe decryption:

key_uuid — unique identifier of the key used for encryption
global_position_start — the global position of the map combination used for encrypting the first byte

The global_position_end is not stored in the encryption metadata because the fixed-length encrypted file metadata contains the plaintext size, which is used to stop decryption before the random suffix.

The encryption metadata is unencrypted by default. When the optional traditional encryption layer (Encryption Method — Optional Traditional Encryption Layer) is enabled, the outer container encrypts it as well.

Encrypted File Metadata
#

encrypted_data begins with a fixed-size encrypted file metadata (FileMetadata) prefix of FILE_METADATA_SIZE = 1024 bytes. This part of the payload is already encrypted with OmegaSafe method. The prefix contains:

name — original file name, used by the decrypt command for the output file name unless overridden by an argument
length — original plaintext length, used for random suffix cutoff during decryption
hash — SHA-256 of the original plaintext, used to verify during decryption that the output matches the original file

Encrypted Payload and Random Suffix
#

Following the encrypted file metadata prefix, encrypted_data contains:

The encrypted original file bytes
An encrypted random suffix

The random suffix size is random in the range 0%–5% of the original file size. Its purpose is to hide the exact plaintext size. The random suffix is also encrypted to ensure uniformity of the process, obstructing any attempt to separate it from the encrypted payload.

6. Speed
#

OmegaSafe delivers practical file-processing throughput for both encryption and decryption. With default preset, on a medium-low tier PC, a representative result is around 160 MB/s for encryption and around 130 MB/s for decryption.

This is roughly 1 Gbps of data throughput. In practical terms, that is faster than typical internet transfer speeds and broadly comparable to office or home LAN speeds, which makes the method suitable for everyday file encryption workflows as well as larger local processing tasks. It also exceeds by multiple times the throughput typically required for real-time communication, including video conferences, which opens multiple potential avenues for implementation.

Throughput remains broadly consistent across different file sizes, but exact results depend on cpu, memory bandwidth, and other hardware components.

Other presets do not vary much in speed, but performance tests on target hardware configuration are highly recommended before production implementation.

7. In-Memory Processing Model and Roadmap Note
#

The current OmegaSafe CLI processing model for encryption and decryption is fully in-memory:

encrypt loads the full input file into memory, then applies the OmegaSafe encryption transform.
decrypt loads the full encrypted_data payload into memory, then applies the OmegaSafe decryption transform.

SecureFileContainer supports chunked import/export for container I/O, but the primary OmegaSafe encrypt/decrypt transformation path is currently in-memory.

Roadmap note: A streaming fallback for insufficient-memory situations is on the roadmap. The planned behavior is that when in-memory processing is not safe for available RAM, OmegaSafe CLI will fall back to streaming file-to-file processing.

For the encrypt and decrypt command references, see OmegaSafe CLI — Command Reference.

8. Optional Traditional Encryption Layer
#

OmegaSafe supports an optional second encryption layer on top of the primary byte-replacement method. It allows to hide the encryption metadata (Encryption Method — Encryption Metadata). This layer can be enabled via:

TRADITIONAL_ENC_LAYER_PASS in config.ini
OMEGASAFE_TRADITIONAL_ENC_LAYER_PASS as an environment variable override

Resolution order is: OMEGASAFE_TRADITIONAL_ENC_LAYER_PASS environment variable, then TRADITIONAL_ENC_LAYER_PASS in config.ini, then no traditional layer if neither source resolves a value. An explicitly empty OMEGASAFE_TRADITIONAL_ENC_LAYER_PASS disables the traditional layer and overrides a non-empty config.ini value.

When set, the outer SecureFileContainer is created in secure (password-protected) mode with full payload encrypted using AES-256-GCM. As a result, even the encryption metadata (key_uuid and global_position_start) is no longer readable without that password. For the OmegaSafe-encrypted file composition, see Encryption Method — Encrypted file structure.

Compatibility requirement: The decrypting side must resolve the same traditional-layer password. A missing or wrong password prevents the container from opening.

For multi-device workflows, configure the same traditional-layer password on both sides before running encrypt or decrypt. If your security posture allows treating key_uuid and global_position_start as non-sensitive, the traditional encryption layer can be skipped.

For setup details, see OmegaSafe CLI — Traditional Encryption Layer.

9. Default Key Configuration Preset
#

The default key configuration preset used by OmegaSafe CLI is:

Nucleus size: 0.25 MB
Rotor size: 0.25 MB per rotor
Number of rotors: 3

This preset (MEDIUM/RECOMMENDED) balances key size on disk, Delta renewal frequency (for device/key compromise blast radius control and ECS sync necessity), processing speed and total encryption capacity. It is suitable for most use cases.

For the default MEDIUM/RECOMMENDED preset, the key capacity summary is:

Field	Value
Alpha/Delta key size on disk	1.00 MB
Alpha/Delta encryption capacity	907.4 GB
Maximum payload file size	907.4 GB
Supported number of Deltas	907,401
Total encryption capacity	823.4 PB

For all available presets (SMALL, MEDIUM/RECOMMENDED, BIG, CUSTOM), their per-preset capacity summaries, the CUSTOM option’s valid configuration ranges, the full capacity guidance table, and all notes shown during interactive key creation, see OmegaSafe CLI — create-key.

10. Secure File Container
#

SecureFileContainer (SFC) is OmegaSafe’s general-purpose container format for packaging internal payloads together and, when needed, protecting the whole container with AES-256-GCM.

OmegaSafe uses SFC in two ways:

Local OmegaSafe CLI storage created by init: omegasafe_keys.sfc, local_cache.sfc, and ecs_storage.sfc. These containers store local key material, local claim cache data, and ECS connection entries, and they are protected by the resolved configuration password; see OmegaSafe CLI — Configuration Password.
Encrypted output files: each .omegasafe file is an SFC containing encrypted_data and encryption_metadata.json, addressed by ENCRYPTED_DATA_UUID and ENCRYPTION_METADATA_UUID. When the optional traditional layer is enabled, this outer container is password-protected as well; see Encryption Method — Optional Traditional Encryption Layer.

config.ini itself is plain-text configuration, not an SFC. SFC is the encrypted storage layer used alongside config.ini for OmegaSafe CLI local data and for transported encrypted files.

11. External Claims Storage
#

External Claims Storage (ECS) is the encryption system component that coordinates encryption key global positions usage, ensuring no map combination is ever reused. OmegaSafe CLI supports two ECS types:

ECS Backend Split Graph
#

flowchart TD
    ECS["External Claims Storage (ECS)"]
    ECS --> HTTP["HTTP ECS
(OmegaSafe API)"]
    ECS --> SFC["SFC ECS
(Secure File Container — local only)"]
    HTTP --> Cloud["OmegaSafe Cloud
(available now)"]
    HTTP --> SH["OmegaSafe Self-Hosted
(planned)"]

    style SH stroke-dasharray: 5 5, stroke: #888, color: #888

HTTP ECS provides OmegaSafe API and is the recommended choice for multi-device and multi-user workflows. SFC ECS is a local file-based option intended for single-device use or testing only.

HTTP ECS is the normal multi-device and multi-user backend for key claims and Delta synchronization. You can set up the HTTP ECS connection during OmegaSafe CLI — init or add it afterwards.

Set up ECS connection during `init`
#

Run omegasafe init without arguments. The interactive prompt asks whether you want to configure an HTTP ECS connection and then guides you through the name, URL, and API key.

Set up ECS connection after `init`
#

If you skipped that part during omegasafe init, add it afterwards with:

omegasafe create-http-ecs
omegasafe list-ecs --json

Running omegasafe create-http-ecs without arguments starts an interactive prompt that asks for the ECS name, URL, and API key. list-ecs --json confirms the connection was registered and shows its UUID, which you will need for subsequent commands.

For the full create-http-ecs command reference including all arguments and non-interactive options, see OmegaSafe CLI — create-http-ecs.

1. ‘Byte Replacement Map’ Model#

2. Global Positions and Key-Space#

3. Alpha and Delta Split#

4. Decryption Flow#

5. Encrypted File Format#

Encrypted file structure#

Outer Structure: SecureFileContainer#

Encryption Metadata#

Encrypted File Metadata#

Encrypted Payload and Random Suffix#

6. Speed#

7. In-Memory Processing Model and Roadmap Note#

8. Optional Traditional Encryption Layer#

9. Default Key Configuration Preset#

10. Secure File Container#

11. External Claims Storage#

ECS Backend Split Graph#

Set up ECS connection during init#

Set up ECS connection after init#

12. Related Topics#