PRODUCTS
Contact Us

Resource Context: The Cornerstone of Entrelid™'s Cryptographic Security Architecture

Entrelid Framework's platform delivers mathematically undiscoverable data storage through our proprietary Cryptographic Storage Address Derivation system—the third layer in our revolutionary three-factor security model.

The Three Layers of Entrelid's Security Model

Entity Authentication

WHO/WHAT you are

  • JWT token validation
  • Proves identity of the requesting entity
  • First security gate for all operations

Relationship Authorization

WHAT relationship exists

  • RDID verification
  • Confirms authorized relationship
  • Controls access permission scope

Cryptographic Storage Address Derivation

WHERE data is located

  • Resource Context computation
  • Mathematically defines data location
  • Makes data undiscoverable without exact inputs

Unlike traditional security models that rely on policy enforcement alone, Entrelid's approach makes unauthorized access mathematically impossible. All three factors are cryptographically required—without any single factor, data doesn't just become denied, it becomes undiscoverable within our vast 128-bit address space.

Understanding Resource Context: Cryptographic Storage Address Derivation

Resource Context is the logical construction of attributes and parameters passed to Entrelid D-ISP servers that determines where and how data is stored or retrieved. It's not just a location descriptor—it's a sophisticated cryptographic derivation mechanism that creates mathematically un-discoverable storage keys.

The three-component path (namespace/domain, entity class, and collection name) combined with the validated RDID and the document's UUID undergoes multiple rounds of information transformation to produce a 128-bit encoded transform. This transform becomes the storage key under which the document is stored and retrieved in our distributed Key-Value data store.

This approach creates a key-space so vast (340 trillion trillion possible values) that brute force discovery is computationally infeasible, even with quantum computing on the horizon.

The Resource Context Components

Path Components

Namespace/domain, entity class, and collection name that create the logical hierarchy for the data

Document UUID

Unique identifier for the specific document being stored or retrieved

Transformation Operations

Multiple rounds of proprietary transformations to create the final 128-bit encoded storage key

Additional Components

Authentication tokens, relationship identifiers, operation modes (GET/POST), and various request parameters that control how data is processed and returned.

This key derivation process ensures that each document's storage location has no mathematical relationship to any other document. Even with complete server access, attackers cannot enumerate or discover what data exists without knowing the exact inputs to the derivation algorithm.

Mathematical Security Properties

Non-Sequential Keys

Storage keys are generated through cryptographic transformations, creating non-sequential values that cannot be iterated through. Even if an attacker discovers one key, there's no way to compute or guess adjacent keys.

Non-Discoverable Data

Unlike traditional databases with catalogs or metadata that reveal what data exists, our system provides no mechanism to discover what storage keys are in use without knowing the exact inputs that generated them.

Non-Pivotable Architecture

Finding one document provides zero information about how to find related documents. Each document exists at its own isolated address in the vast keyspace, with no traversable relationships between them.

Cryptographically Vast Key-space

With 2^128 possible addresses (approximately 340 trillion trillion), the key-space is so vast that even if you could check 1 billion keys per second, it would take longer than the age of the universe to enumerate all possibilities.

Common Hierarchical Format (CHF) Document Structure

When data is stored in the Entrelid system, it's parsed into our proprietary Common Hierarchical Format (CHF). This structured format allows the server to:

Efficient Storage

CHF optimizes document structure for rapid traversal and retrieval, enabling our exceptional performance metrics: up to 145 fully indexed 1K document writes/second and 175,000 reads/second per server.

Security Integration

Every data node (d-node) in a CHF document can have associated security parameters (s-nodes) that control access, visibility, and redaction rules at a granular level.

Query Optimization

The hierarchical structure allows the server to efficiently traverse the document to find matching query tags or fields without loading the entire document into memory.

During retrieval operations, the server locates the document using the computed storage key, traverses the CHF structure to find requested data nodes, applies security parameters for redaction, and returns the properly formatted result (as objects, arrays, or elements).

The Request-Response Flow in Entrelid

Request Initiation

Client constructs a Resource Context with path components, document ID, authentication token (JWT), relationship identifier (RDID), and operation parameters

Server Routing

Request is directed to the appropriate server based on the queue-id in the Entity's profile, ensuring jurisdictional compliance

Authentication & Authorization

Server validates JWT token (WHO) and RDID (WHAT relationship) before proceeding

Storage Key Computation

Server computes the 128-bit storage key using the Resource Context components

Operation Execution

Server performs requested GET or POST operation using the computed storage key

Response Generation

Server returns document ID (for POST) or requested document fragment in JSON format (for GET), along with success/error code

This entire flow ensures that data access is not just authorized but mathematically defined by the three security factors. Without the correct inputs to generate the exact storage key, the data becomes effectively invisible within the system.

NATS JetStream Integration: Distributed Security with Geographic Control

Entrelid's integration with Open Source NATS JetStream messaging adds crucial capabilities to our security architecture:

  • Location Independence: Topic-based routing allows data to flow seamlessly while maintaining security
  • Jurisdictional Compliance: Server placement ensures data residency requirements (GDPR, CCPA) are automatically met
  • Automatic Failover: Transparent resilience without manual configuration or security compromises
  • Stream-Based Recovery: Reliable automatic synchronized backup and disaster recovery without exposing security parameters

"European data stays in Europe, US data stays in US. The 'right to be forgotten' is instant—revoke an RDID and that entity's access disappears everywhere, immediately, without touching the data itself."

The queue-id in each Entity's profile ensures that all requests are routed to servers in the appropriate jurisdiction, maintaining compliance while preserving our cryptographic security model.

Performance Metrics: Security Without Sacrifice

145

Writes/Second

Fully indexed 1K documents with complete security controls

145K

Reads/Second

Per server under typical operational conditions

2^128

Key Space

Possible unique storage addresses (340 trillion trillion)

These aren't theoretical benchmarks—they're measured performance in real-world deployments. Our architecture delivers enterprise-grade throughput while maintaining the full security guarantees of our three-factor model.

Transaction Control Through TTL-Based Locking

Entrelid implements a novel approach to distributed transactions using Document Time-To-Live (TTL) based locking mechanisms. This clever implementation:

  • Uses document expiration to implement saga patterns without traditional two-phase commit
  • Maintains transaction integrity across distributed nodes
  • Prevents deadlocks through automatic expiration
  • Scales with the system without centralized coordination

This approach aligns perfectly with our security architecture—transaction control remains cryptographically bound to the Resource Context, preventing unauthorized transaction manipulation while ensuring data consistency.

How Resource Context Revolutionizes Security Architecture

Traditional database security relies on access control policies enforced by the database engine. Even with robust policies, an administrator with sufficient privileges can still discover what data exists and potentially access it.

With Entrelid's Cryptographic Storage Address Derivation:

"Even if attackers steal our entire database, they can't find your data. The storage addresses are cryptographically derived—without the exact inputs, your data is mathematically invisible."

This fundamental architectural innovation goes beyond access control to make unauthorized data discovery computationally infeasible, even with coming quantum computation, creating a new transformational data security that exceeds regulatory requirements and enterprise security expectations.

Beyond Security: The Strategic Value of Resource Context

Separation of Concerns

By separating data discovery from data access, Entrelid creates a security model where administrative access to systems doesn't automatically grant data access—a crucial distinction for zero-trust architectures.

Instant Revocation

The "right to be forgotten" is implemented through relationship revocation (RDID)—once revoked, the data becomes mathematically undiscoverable without having to delete or encrypt it.

Jurisdictional Agility

As regulatory requirements evolve, Entrelid's architecture allows for dynamic routing and storage strategies without compromising the core security model or requiring data migration.

Resource Context isn't just a security feature—it's the cornerstone of Entrelid's architectural advantage. By making data location a mathematical function rather than a discoverable property, we've created a system where security is built into the fundamental fabric of data storage rather than layered on as policy enforcement.