Skip to content

Fragmentation Architecture and Quantum Secure Protection

A detailed overview of how eXate fragments encryption, keys, and validation components while combining AES-GCM-SIV, modular cryptography, distributed storage, and ABAC to create a mathematically verifiable and quantum-resilient security model.

Introduction

eXate provides a modular, extensible, and mathematically enforced platform for protecting sensitive data across distributed and regulated environments. The platform is designed to fragment any encryption algorithm. Today, eXate applies fragmentation to AES-GCM-SIV with a configurable key size, using 256 bits as the default but supporting higher strength keys when required.

Unlike traditional encryption architectures, eXate fragments ciphertext, key material, and hash-based validation components, ensuring that no single system contains sufficient information to reconstruct protected data.

Reconstruction of any protected value requires both the complete set of required fragments and successful attribute-based access control checks (ABAC). These checks verify that the requesting user or system is allowed to access the specific data attribute before eXate retrieves any shards from the distributed cache. By combining computational security from modern encryption algorithms with optional information-theoretic security from Shamir Secret Sharing, eXate provides a layered defence that remains resilient even against emerging quantum computing threats.

Cryptographic Modularity

The eXate platform supports the fragmentation of any encryption algorithm. AES-GCM-SIV is integrated today but can be replaced or combined with additional techniques, including post-quantum cryptographic algorithms, format-preserving encryption, deterministic encryption, or searchable encryption. This allows organisations to apply the correct encryption method at a cell or field level based on functionality, regulatory obligations, and risk profile.

Cell Level Encryption

Every attribute is encrypted independently, so that first name, last name, address, and date of birth each use distinct keys. This ensures fine-grained isolation, reduces blast radius, and supports granular policy enforcement.

Cell Level Algorithm Choice

Specific fields can use specialised algorithms only where required, such as:

  • Searchable encryption for lookup use cases
  • Format-preserving encryption where data shape must remain unchanged
  • Deterministic encryption for matching or joins
  • AES-GCM-SIV for authenticity and strong symmetric protection

Algorithm Migration and Evolution

eXate supports live migration of algorithms. Each ciphertext includes metadata identifying the algorithm and key version used. When organisations wish to upgrade cryptography, eXate can seamlessly decrypt and re-encrypt using stronger algorithms while supporting backward compatibility and defined time-to-live periods for older cryptographic material.

Fragmentation Flow

The complete base fragmentation flow using AES-GCM-SIV:

1. Encryption

A full ciphertext C is generated using AES-GCM-SIV:

C = AES-GCM-SIV_K(P)

2. Ciphertext Fragmentation

The ciphertext is fragmented into n parts:

C → {C_1, C_2, ..., C_n}

Each fragment contains only part of the full encrypted value.

3. Hash Generation

A SHA-256 hash of the full ciphertext is created:

H = SHA256(C)

4. Token Construction

A substring of the hash is appended to the first fragment:

T = C_1 || substring(H)

The substring length is determined based on required entropy, the number of shards, and collision avoidance requirements.

5. Storage

The remaining fragments C_2 through C_n are stored in the distributed cache under the index SHA256(T). This ensures that fragments cannot be retrieved unless the correct token is presented, derived from a valid first fragment.

Key Management Architecture

eXate uses a multi-layer key hierarchy designed for security, isolation, and cryptographic lifecycle management.

Data Keys

The encryption key for each ciphertext is generated from two underlying data keys:

  • Key 1 represents what the data is about (for example, first name)
  • Key 2 represents who the data belongs to (the data subject)

This dual-key approach enables both attribute-level and data-subject-level isolation.

Master (Envelope) Key

Both data keys are encrypted with a master key, typically stored in a hardware security module (HSM):

DataKey_i = Enc_MasterKey(RawKey_i)

Disabling the master key halts all encryption activity immediately.

Cryptographic Erasure

Because Key 2 is tied to the data subject, removing or invalidating it enforces the right to be forgotten. Any ciphertext requiring that key can no longer be decrypted.

Key Rotation

All keys can be rotated. Ciphertext metadata indicates the keys and algorithm versions used, enabling forward key migration, backward compatibility, TTL-based expiry of retired keys, and incremental, low-risk algorithm upgrades.

Attribute Based Access Control (ABAC)

ABAC is enforced before any remote fragments are retrieved. Metadata contained in the primary fragment is evaluated to confirm requester identity and permissions, data subject permissions, attribute type, regional and jurisdictional requirements, purpose and context of access, and algorithm-level rules.

If ABAC fails, no fragments are retrieved and no decryption attempt occurs.

Shamir Secret Sharing (Optional Extension)

Although not part of the base flow today, eXate can extend fragmentation using Shamir Secret Sharing (SSS) to allow threshold-based reconstruction.

The protected secret S is embedded into a polynomial of degree t-1:

f(0) = S
f(x) = S + a_1*x + a_2*x^2 + ... + a_(t-1)*x^(t-1)

Shares are generated as Share_i = (x_i, f(x_i)), and the secret is reconstructed as S = f(0).

If fewer than t shares are available, the shares provide no information about the secret: P(Secret | Insufficient Shares) = P(Secret). This provides information-theoretic protection independent of computational difficulty.

Today, eXate requires full fragment presence for reconstruction, but SSS can be added to support reduced threshold models depending on operational resilience requirements.

Information Theoretic Security and Quantum Resistance

Information-theoretic security guarantees that partial information provides no advantage, even with infinite computing power. When combined with AES-GCM-SIV, fragmentation, distributed storage, strict ABAC enforcement, and optional SSS, eXate provides a defence model that remains resilient even as quantum computing capabilities evolve. Even if quantum attacks reduce the hardness of symmetric cipher brute forcing, attackers cannot reconstruct secrets without meeting strict mathematical and policy constraints.

Distributed Storage and Isolation

Fragments stored outside the source system are written to a distributed cache. This ensures that no single breach yields complete information, key material is isolated, the attack surface is reduced, reconstruction requires validated tokens, and ABAC and cryptographic integrity checks must be passed.

No system alone possesses sufficient information to reconstruct sensitive data.

Summary

The eXate platform provides a modular, mathematically enforced architecture for protecting sensitive data, supporting fragmentation of any encryption algorithm, AES-GCM-SIV with configurable key sizes, SHA-256 validation flows, distributed storage of ciphertext fragments, dynamic algorithm migration, dual data key generation with master key protection, right to be forgotten via data subject key removal, full lifecycle key rotation and TTL, optional Shamir Secret Sharing for threshold decryption, and ABAC enforcement before any fragment retrieval.