Request Demo
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 pillar in our revolutionary three-factor security model.
The Three Pillars 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 undiscoverable 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 hashing to produce a 128-bit encoded hash. This hash becomes the storage key under which documents are stored and retrieved in our distributed key-value data store.
This approach creates a keyspace 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
Hashing Operations
Multiple rounds of proprietary hashing to create the final 128-bit encoded storage key
Storage Key
The final cryptographic address where data is stored in the distributed KV store

The Resource Context also includes 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 hashing, 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 Keyspace
With 2^128 possible addresses (approximately 340 trillion trillion), the keyspace 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: 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
175K
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.

The Entrelid system scales horizontally with minimal configuration overhead. Each additional server contributes its full performance capacity to the cluster without compromising security or requiring complex sharding strategies.
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.

The TTL-based locking mechanism is particularly valuable in high-availability deployments where traditional distributed transaction coordinators would create a single point of failure.
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.