GitHub Repository: https://github.com/Qeltrix/Qeltrix-v6
PyPI:https://pypi.org/project/qeltrix-v6/
⚠️ Proof-of-concept. Not for production or security-critical use without an independent cryptographic audit.
The Problem with Encryption Today
Most encryption tools work the same way they did decades ago: you hand over a file, it gets locked, and to access any part of it — even a single byte — you must decrypt the entire thing first. Want to stream a 4K video stored securely in the cloud? Download it all. Want to jump to chapter 12 of an encrypted audiobook? Decrypt everything up to that point. This "all-or-nothing" model was acceptable when files were small and bandwidth was cheap. Neither of those things is true anymore.
Qeltrix V6 is a new kind of encrypted container format that breaks this assumption entirely. It is built from the ground up to behave like a live, seekable stream — meaning you can jump to any point inside an encrypted file and begin reading immediately, without touching the rest of the data.
What Makes V6 Different: Stream-First Architecture
The core idea behind Qeltrix V6 is deceptively simple: instead of encrypting a file as one monolithic blob, V6 splits data into discrete, independently encrypted blocks. Each block carries its own cryptographic identity — its own key, its own nonce, its own integrity tag, and its own metadata. The result is a container that behaves less like a locked safe and more like an encrypted database: you can query exactly the part you need.
Traditional Encryption:
┌─────────────────────────────────────────────┐
│ ONE BIG ENCRYPTED BLOB │
│ (Must decrypt all to access any part) │
└─────────────────────────────────────────────┘
Qeltrix V6 Block Architecture:
┌──────────┬──────────┬──────────┬──────────┐
│ Block 0 │ Block 1 │ Block 2 │ Block N │
│ [Header] │ [V6-C] │ [V6-C] │ [Footer] │
│ [MK Env] │ [Data] │ [Data] │ [Index] │
└──────────┴──────────┴──────────┴──────────┘
↑ Each block independently seekable and verifiable
How the System is Organized
Qeltrix V6 uses a hybrid C + Python architecture that gives you the best of both worlds: raw C speed for the heavy structural work, and Python's mature cryptography ecosystem for the security layer.
┌──────────────────────────────────────────────────────────┐
│ Qeltrix V6 System │
│ │
│ ┌─────────────────────┐ ┌──────────────────────────┐ │
│ │ C Shared Library │ │ Python Crypto Layer │ │
│ │ (libqeltrix_v6) │ │ │ │
│ │ │ │ ● AES-256-GCM │ │
│ │ ● Block framing │◄──►│ ● ChaCha20-Poly1305 │ │
│ │ ● Permutation │ │ ● HKDF-SHA256 (CDK) │ │
│ │ ● Header/footer │ │ ● SHA-256 hashing │ │
│ │ ● TCP networking │ │ ● Master key wrapping │ │
│ │ ● HTTP parsing │ │ ● Metadata encryption │ │
│ │ ● Seek math │ │ │ │
│ └─────────────────────┘ └──────────────────────────┘ │
│ │
│ ┌───────────────┐ ┌───────────────┐ ┌──────────────┐ │
│ │ pack/unpack │ │ GatewayServer │ │ SeekServer │ │
│ │ (container) │ │ (TCP encrypt) │ │ (HTTP+Range) │ │
│ └───────────────┘ └───────────────┘ └──────────────┘ │
└──────────────────────────────────────────────────────────┘
The C library handles everything that needs to be fast: splitting data into blocks, framing them for the wire, computing the mathematics of seeking, and managing TCP connections. Python takes care of everything that needs to be correct: key derivation, AEAD ciphers, and the authentication chain that ensures no one has tampered with your data.
The Security Model: Layers All the Way Down
V6 doesn't rely on a single encryption step. It implements a dual-layer key hierarchy that binds every block of data to both its content and its position in the file:
Security Hierarchy:
Passphrase / User Credential
│
▼ (PBKDF2 / HKDF)
┌─────────────────────┐
│ Master Key (MK) │ ← Root of trust; stored encrypted in container header
└─────────────────────┘
│
▼ (HKDF-SHA256 + block index + data hash + salt)
┌─────────────────────┐
│ Content Derived │ ← Per-block key, unique to BOTH this block's
│ Key (CDK) │ position AND its content
└─────────────────────┘
│
▼ (AES-256-GCM or ChaCha20-Poly1305 AEAD)
┌─────────────────────┐
│ Encrypted Block │ ← Authenticated ciphertext; tamper-evident
│ + V6-C Metadata │
└─────────────────────┘
What makes this powerful is the Content Derived Key (CDK). This per-block key is derived using HKDF and incorporates both the block's sequential index and a SHA-256 hash of its raw content. This means two identical blocks in different positions get different keys, and moving a block to a different position without re-encrypting will cause authentication to fail — the system detects it.
The V6-C metadata — which holds the per-block IV, salt, integrity hash, and the wrapped CDK — is itself encrypted with the master key. Even an attacker who intercepts the container cannot learn anything about its internal structure without the master key.
Real-Time Seekable Access: How Range Requests Work
The most practically powerful capability of V6 is its native support for HTTP Range Requests. This is the same mechanism that allows you to seek in a YouTube video without buffering from the start. V6 brings this capability to encrypted files.
HTTP Range Request Workflow:
Client SeekServer Container
│ │ │
│ GET /video.qltx │ │
│ Range: bytes=50000000- │ │
│──────────────────────────────►│ │
│ │ 1. Parse range header │
│ │ 2. Calculate which blocks │
│ │ cover byte 50,000,000 │
│ │─────────────────────────────►│
│ │ 3. Read only those blocks │
│ │◄─────────────────────────────│
│ │ 4. Decrypt blocks │
│ │ 5. Slice to exact range │
│ 206 Partial Content │ │
│◄──────────────────────────────│ │
│ (Only requested bytes) │ │
The container's footer stores a VFS (Virtual File System) index — a table that maps byte ranges in the original file to their corresponding block positions in the container. When a range request arrives, the SeekServer consults this index, fetches only the minimum necessary blocks, decrypts them, and returns exactly the bytes that were requested. A 20 GB encrypted video file can serve a seek to the 18-minute mark in milliseconds.
The Gateway: A Full Encryption Router for the Network Layer
Beyond static files, Qeltrix V6 includes a GatewayServer — a standalone TCP encryption router that can wrap any stream of data in V6's block-encrypted format as it moves across the network. This is not a VPN, and it is not a proxy in the traditional sense. It is something more specific and more powerful: a transparent encryption boundary that can be inserted between any two points in a network topology without modifying the applications on either side.
This capability elevates V6 from a file format to a network security primitive — a building block for constructing encrypted data infrastructure.
What the Gateway Actually Does
When data arrives at the GatewayServer over TCP, it does not simply forward it. It performs the full V6 encryption pipeline — in real time, on every byte — before the data leaves the gateway's other side. The receiving end gets a proper V6 block stream: framed, authenticated, and encrypted. If the receiving end is another V6-aware component (such as a storage backend or another gateway), it can verify and decrypt each block independently as it arrives.
The V6 Gateway Processing Pipeline (per connection):
Incoming raw bytes
│
▼
┌──────────────────────────────────────────────────────┐
│ GatewayServer │
│ │
│ ┌─────────────┐ │
│ │ Accumulate │ Buffer incoming bytes until a full │
│ │ into blocks │ block boundary is reached │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Hash block │ SHA-256 of raw block content │
│ │ content │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Derive CDK │ HKDF(MasterKey, block_idx, hash, │
│ │ │ salt) → unique per-block key │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ AEAD │ AES-256-GCM or ChaCha20-Poly1305 │
│ │ Encrypt │ → ciphertext + 16-byte auth tag │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Frame as V6 │ Write block prefix + V6-C metadata │
│ │ wire block │ + ciphertext to output stream │
│ └──────┬──────┘ │
└─────────┼────────────────────────────────────────────┘
│
▼
Encrypted V6 block stream (to destination or storage)
This pipeline runs concurrently across multiple connections using a thread pool, meaning a single gateway instance can serve many simultaneous clients without serializing their encryption work.
Gateway Topology: Three Deployment Modes
The GatewayServer supports three distinct deployment topologies, selected at startup.
Mode 1 — Reflect Mode (Loopback Encryption Testing)
In reflect mode, the gateway receives a raw stream, encrypts it into V6 blocks, and sends the encrypted stream back to the sender. This is useful for testing, benchmarking, and any scenario where you want to measure V6 overhead in isolation without setting up a full two-sided deployment.
┌──────────────────────────────────────────────────┐
│ Reflect Mode │
│ │
│ Client App GatewayServer │
│ │ │ │
│ │ raw TCP stream ───────►│ │
│ │ │ encrypt │
│ │◄─── encrypted V6 ────────│ │
│ │ stream back │ │
│ │
│ Use case: local testing, encryption benchmarks │
└──────────────────────────────────────────────────┘
Mode 2 — Forward/Router Mode (Encryption Proxy)
In router mode, the gateway sits between a data source and a destination. Raw data comes in from the source, gets encrypted into V6 blocks, and is forwarded onward to the configured destination host and port. The destination receives only ciphertext — it never sees the plaintext.
┌────────────────────────────────────────────────────────────┐
│ Router Mode │
│ │
│ Data Source GatewayServer Destination │
│ (app / service) │ (storage, relay) │
│ │ │ │ │
│ │──raw TCP────►│ │ │
│ │ │──V6 encrypted stream─►│ │
│ │ │ │ │
│ │ [encrypt + frame] [receives │
│ │ ciphertext] │
│ │
│ Use case: zero-trust data pipelines, encrypted relay │
└────────────────────────────────────────────────────────────┘
Mode 3 — Chained Gateway Mode (Multi-Hop Encryption)
Multiple GatewayServer instances can be chained together. The output of one gateway (an encrypted V6 stream) feeds into the input of the next, which re-encrypts it under a different master key. This creates a layered encryption topology where no single node holds the full decryption capability — each hop peels one layer.
┌────────────────────────────────────────────────────────────────┐
│ Chained Gateway Mode │
│ │
│ Source Gateway A Gateway B Destination │
│ │ (MK-Alpha) (MK-Beta) │ │
│ │ │ │ │ │
│ │──raw──────►│ │ │ │
│ │ │──V6[MK-α]────►│ │ │
│ │ │ │──V6[MK-β]──────►│ │
│ │ │ │ (double │ │
│ │ │ │ encrypted) │ │
│ │
│ Each gateway adds an independent encryption layer. │
│ Compromise of one node does not expose plaintext. │
└────────────────────────────────────────────────────────────────┘
The Gateway as an Encryption Router: Network-Level Placement
One of the more significant capabilities of the GatewayServer is where it can be placed in a network topology. Because it operates at the TCP socket level and is completely transparent to the applications on either side, it can be dropped into virtually any network path without code changes.
┌───────────────────────────────────────────────────────────────────┐
│ V6 Gateway as a Network Encryption Router │
│ │
│ UNTRUSTED NETWORK │
│ ┌─────────────────────┐ │
│ │ (ISP / Cloud / WAN)│ │
│ └─────────────────────┘ │
│ ▲ ▼ │
│ TRUSTED ZONE A │ TRUSTED ZONE B │
│ ┌────────────────┐ │ ┌────────────────┐ │
│ │ App Server │ │ │ Storage / │ │
│ │ Database │ │ │ Analytics │ │
│ │ Log Source │ │ │ Backup Node │ │
│ └───────┬────────┘ │ └────────┬───────┘ │
│ │ raw │ raw │ │
│ ▼ │ ▼ │
│ ┌───────────────┐ │ ┌───────────────┐ │
│ │ V6 Gateway │─────────────┘ │ V6 Gateway │ │
│ │ (Encrypt) │ encrypted V6 stream │ (Decrypt) │ │
│ └───────────────┘ ───────────────────────►└───────────────┘ │
│ │
│ ● The untrusted network sees only V6 ciphertext │
│ ● No application changes required on either side │
│ ● Each block is independently authenticated │
└───────────────────────────────────────────────────────────────────┘
This pattern is particularly relevant for cloud deployments where data must traverse shared infrastructure. The V6 gateway pair creates an encrypted tunnel at the application-data level — distinct from TLS (which secures the transport) in that the data itself is encrypted in a structured, auditable format that can be stored, replayed, and verified independently of the connection.
Concurrent Connection Handling
The GatewayServer uses a ThreadPoolExecutor to handle multiple simultaneous connections. Each connection gets its own encryption context — its own block counter, its own per-block key derivation chain — so connections are completely isolated from each other at the cryptographic level.
GatewayServer — Concurrent Architecture:
┌─────────────────────────────────────────────────────────┐
│ │
│ Connection 1 ──► Worker Thread 1 ──► V6 Stream Out 1 │
│ Connection 2 ──► Worker Thread 2 ──► V6 Stream Out 2 │
│ Connection 3 ──► Worker Thread 3 ──► V6 Stream Out 3 │
│ Connection N ──► Worker Thread N ──► V6 Stream Out N │
│ │
│ Each worker maintains: │
│ ● Independent block counter (block_index) │
│ ● Independent CDK derivation chain │
│ ● Independent AEAD cipher state │
│ ● Independent stats (bytes_in, bytes_out) │
│ │
│ Shared across all workers (read-only after init): │
│ ● Master Key │
│ ● Cipher selection (AES or ChaCha20) │
│ ● Block size configuration │
└─────────────────────────────────────────────────────────┘
This design means encryption throughput scales linearly with the number of available CPU cores up to the thread pool limit. A gateway instance running on an 8-core server can simultaneously encrypt 8 independent streams at full CPU speed.
Gateway vs. SeekServer: Complementary Roles
It is worth distinguishing the two server components clearly, since they solve related but different problems:
┌───────────────────────────────────────────────────────────────┐
│ GatewayServer vs. SeekServer │
│ │
│ ┌──────────────────────┐ ┌──────────────────────────────┐ │
│ │ GatewayServer │ │ SeekServer │ │
│ │ │ │ │ │
│ │ Protocol: TCP │ │ Protocol: HTTP/1.1 │ │
│ │ Direction: Encrypt │ │ Direction: Decrypt + Serve │ │
│ │ Input: Raw │ │ Input: .qltx container │ │
│ │ stream │ │ Output: Plaintext bytes │ │
│ │ Output: V6 │ │ Seeking: Range Requests │ │
│ │ stream │ │ │ │
│ │ Use when: │ │ Use when: │ │
│ │ ● Encrypting data │ │ ● Serving encrypted files │ │
│ │ in transit │ │ to media players, │ │
│ │ ● Building zero- │ │ browsers, apps │ │
│ │ trust pipelines │ │ ● Partial extraction from │ │
│ │ ● Transparent │ │ large archives │ │
│ │ encryption proxy │ │ │ │
│ └──────────────────────┘ └──────────────────────────────┘ │
│ │
│ Together: Encrypt at source (Gateway) → Store → Serve │
│ on demand with seeking (SeekServer) │
└───────────────────────────────────────────────────────────────┘
In a complete deployment, the GatewayServer encrypts data as it is produced and streams it to storage. The SeekServer then serves that stored, encrypted data to consumers — decrypting only the portions they request. The two components form a complete end-to-end pipeline.
Full End-to-End Pipeline Diagram
┌──────────────────────────────────────────────────────────────────────┐
│ Complete V6 Encrypted Data Infrastructure │
│ │
│ PRODUCTION │ UNTRUSTED │ CONSUMER │
│ SIDE │ STORAGE/NET │ SIDE │
│ │ │ │
│ ┌──────────────┐ │ │ ┌──────────────────┐ │
│ │ App / Camera │ │ │ │ Media Player / │ │
│ │ Sensor / DB │ │ │ │ Browser / Client │ │
│ └──────┬───────┘ │ │ └────────┬─────────┘ │
│ │ raw data │ │ │ HTTP Range │
│ ▼ │ │ ▼ Request │
│ ┌──────────────┐ │ ┌───────────┐ │ ┌──────────────────┐ │
│ │ V6 Gateway │────┼──►│ .qltx │◄──┼────│ SeekServer │ │
│ │ (Encrypt) │ │ │ Storage │ │ │ (Decrypt + │ │
│ └──────────────┘ │ │ (Cloud / │ │ │ Serve range) │ │
│ │ │ Disk) │ │ └──────────────────┘ │
│ Master Key held │ │ │ │ Master Key held │
│ by Gateway only │ │ Sees only │ │ by SeekServer only │
│ │ │ ciphertext│ │ │
└──────────────────────┴───┴───────────┴───┴──────────────────────────┘
The storage layer — whether a cloud object store, a NAS, or a CDN — holds only encrypted V6 containers. It has no access to the master key, and therefore no ability to read the data it stores. The encryption and decryption capabilities are held exclusively by the gateway (on ingress) and the SeekServer (on egress), both of which operate within the trusted boundary.
Gateway-Specific Use Cases
Zero-Trust Internal Data Bus
In a microservices architecture, services that exchange sensitive data (user records, financial transactions, health data) can route their traffic through V6 gateway pairs. The internal network sees only V6 ciphertext. Even if an internal service is compromised, it cannot read traffic it wasn't issued a key for.
┌──────────────────────────────────────────────────────────┐
│ Zero-Trust Microservice Mesh │
│ │
│ Service A GW-A Network Fabric GW-B Svc B │
│ │ │ │ │ │ │
│ │──plaintext─►│ │ │ │ │
│ │ │──V6 crypt─►│──V6 crypt──►│ │ │
│ │ │ │ │─plain►│ │
│ │
│ Service C GW-C │ GW-D Svc D │
│ │ │ │ │ │ │
│ │──plaintext─►│──V6 crypt─►│──V6 crypt──►│─plain►│ │
│ │
│ Each service pair has its own Master Key. │
│ GW-A cannot decrypt GW-C's traffic. │
└──────────────────────────────────────────────────────────┘
Encrypted Sensor / IoT Data Collection
IoT devices and sensors often transmit data over networks with little to no security. A V6 gateway deployed at the network edge collects raw sensor streams, encrypts them in real time into V6 containers, and forwards them to a cloud backend. The backend stores only ciphertext. Analysis infrastructure that holds the key can then seek into specific time windows without pulling entire archives.
Sensors ──► Edge Gateway (V6 Encrypt) ──► Cloud Storage (.qltx)
│
Analytics seeks specific
time windows via SeekServer
Encrypted Audit Trail / Compliance Logging
Compliance environments (HIPAA, PCI-DSS, SOC 2) require that sensitive logs be tamper-evident and access-controlled. Running audit log streams through a V6 gateway produces containers where every block is authenticated — any deletion or modification breaks the authentication chain and is immediately detectable. Auditors with the key can seek to any time window; no one else can read the logs at all.
Possible Use Cases
1. Secure Cloud Video Streaming
Store large video libraries encrypted in cloud storage (S3, GCS, etc.) and serve them with HTTP Range Request support. Users can seek and play without the server — or the storage provider — ever seeing the plaintext. V6's block structure means scrubbing to any point in a 2-hour film requires decrypting at most a few hundred kilobytes.
2. Encrypted Media CDN
Build a content delivery network where the CDN nodes hold only encrypted blocks. The keys never leave your infrastructure. Even if a CDN node is compromised, an attacker gets only ciphertext — and individual blocks are useless without the master key.
3. Secure Backup with Partial Restore
Back up large datasets block by block. When you need to restore a single file from a 500 GB backup archive, seek directly to that file's blocks and decrypt only those. No full-archive extraction needed.
4. Real-Time Encrypted Logging
Use the Gateway Server in front of a log aggregation system. Log data is encrypted in transit and stored in V6 containers, but log analysis tools that hold the key can still seek to specific time windows within a day's logs without downloading the full day.
5. Secure File Sharing with Selective Access
Distribute an encrypted container where different authorized parties can access different byte ranges (corresponding to different logical sections). Since each block has its own CDK derived from the master key, access control can be scoped to specific block ranges.
6. Encrypted Game Asset Streaming
Game engines stream assets from disk or network as they're needed. V6 enables those assets to be stored encrypted without performance penalties — the engine requests the exact byte range for a texture or audio clip, and only that range is decrypted.
7. Tamper-Evident Archival
Every block carries a SHA-256 integrity hash and an AEAD authentication tag. Any modification to any byte of a V6 container — even a single bit flip — causes decryption of the affected block to fail with an authentication error. This makes V6 containers a natural fit for archival storage where data integrity must be provable.
8. Privacy-Preserving Data Pipelines
In data processing pipelines, intermediate datasets can be stored as V6 containers. Each pipeline stage holds only the master key it needs to access its assigned blocks, and the encrypted metadata ensures that even the schema and structure of the data remain confidential.
Performance Design
V6 is built to be fast. The block architecture is inherently parallelizable: each block is independent, so packing and unpacking use a ThreadPoolExecutor to process multiple blocks simultaneously across all CPU cores. On modern hardware, this approach can fully saturate the memory and I/O bandwidth available, rather than being bottlenecked by a single encryption thread.
For cipher choice, V6 offers:
- AES-256-GCM — the hardware-accelerated default. On any CPU with AES-NI instructions (most devices manufactured after 2010), this is extremely fast.
- ChaCha20-Poly1305 — the mobile-friendly alternative. Designed to be fast in software on CPUs without AES hardware acceleration, making it ideal for IoT devices or older mobile hardware.
Both options provide AEAD (Authenticated Encryption with Associated Data), meaning every decrypt operation simultaneously verifies that the data has not been altered.
The Master Key Problem: How Does V6 Actually Share It?
This is the most important practical question about the system, and it deserves a direct answer.
The Master Key (MK) is a 32-byte symmetric secret. It lives only in process memory — never written to disk in plaintext, never transmitted by V6 itself. The container header stores an encrypted copy of the MK (wrapped with AES-GCM using a passphrase-derived key), but that encrypted blob is useless without the passphrase or raw key that created it. Every operation — pack, unpack, seek_extract, GatewayServer, SeekServer — requires the caller to supply the MK at runtime.
This raises an unavoidable question: how do two parties — a GatewayServer on one machine and a SeekServer on another — both end up holding the same MK without transmitting it over the wire in a way an attacker could intercept?
V6 intentionally does not solve this problem. The gateway is a routing and encryption component. Key distribution is a separate concern, and deliberately left to the operator. This is the right separation of responsibilities — but it does mean you need to design the key exchange layer yourself when moving toward production.
The Gateway Does Not Manage Keys — By Design
┌──────────────────────────────────────────────────────────────────┐
│ What V6 Gateway Does vs. Does NOT Do │
│ │
│ ✓ DOES: ✗ DOES NOT: │
│ ● Accept MK at startup ● Generate or negotiate MK │
│ ● Hold MK in process memory ● Transmit MK over the wire │
│ ● Derive CDKs from MK ● Store MK anywhere on disk │
│ ● Encrypt/decrypt streams ● Authenticate remote parties │
│ ● Route encrypted data ● Manage key rotation │
│ ● Track stats per connection ● Distribute MK to new nodes │
│ │
│ The MK must arrive from OUTSIDE, via an external mechanism. │
└──────────────────────────────────────────────────────────────────┘
This design is correct for a routing component — it mirrors how systems like nginx handle TLS certificates: the server doesn't generate your CA; you bring the cert to it. The gateway is an encryption engine, not a key authority.
How to Distribute the MK Safely: Three Approaches
When two V6 nodes need to share the same MK, the MK itself must travel over some channel. That channel needs to be secure. Here are the standard approaches, from simplest to most production-grade:
Approach 1 — Diffie-Hellman Key Exchange (ECDH)
Two parties can arrive at a shared secret without ever transmitting the secret itself. Using Elliptic Curve Diffie-Hellman (ECDH), each side generates an ephemeral key pair. They exchange only public keys. Each side independently computes the same shared secret, which is then used as (or to derive) the MK.
ECDH Master Key Exchange for V6:
Node A (Gateway) Node B (SeekServer)
│ │
│ Generate ephemeral │ Generate ephemeral
│ keypair (privA, pubA) │ keypair (privB, pubB)
│ │
│────── send pubA ─────────────►│
│◄───── send pubB ──────────────│
│ │
│ shared = ECDH(privA, pubB) │ shared = ECDH(privB, pubA)
│ MK = HKDF(shared, context) │ MK = HKDF(shared, context)
│ │
│ Both now hold identical MK. │
│ The MK was never on the wire.│
This is how TLS establishes session keys. The public key exchange happens in the clear; the secret never leaves either machine. For V6, a pre-connection ECDH handshake between gateway nodes could establish the MK before the stream begins.
Approach 2 — RSA Key Encapsulation
If one party has an RSA public key for the other, they can encrypt the MK under that public key and transmit the ciphertext. Only the holder of the RSA private key can recover the MK. This is simpler to implement than a full DH exchange but requires a pre-existing PKI (public key infrastructure) — each node needs a key pair, and the parties need a way to trust each other's public keys.
RSA MK Distribution:
Key Authority / Operator
│
│ Encrypt MK with Node B's RSA public key
│ → sends ciphertext to Node B
│
Node B decrypts with private key → recovers MK
Node A receives MK via secure out-of-band channel
│
Both nodes now hold MK. RSA ciphertext was safe to transmit.
Approach 3 — External Key Management Service (KMS)
In cloud environments, services like AWS KMS, HashiCorp Vault, or Google Cloud KMS act as trusted third parties that hold and distribute secrets. Neither the gateway nor the seek server ever holds the MK long-term; they request it from the KMS at startup, authenticated by their cloud identity (IAM role, service account, etc.).
KMS-Based MK Distribution:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ V6 Gateway │ │ KMS │ │ V6 SeekSrv │
│ │ │ (Vault / │ │ │
│ startup: │──────►│ AWS KMS / │◄──────│ startup: │
│ "give me │ │ etc.) │ │ "give me │
│ MK for │ │ │ │ MK for │
│ stream X" │◄──────│ verifies │──────►│ stream X" │
│ │ MK │ identity │ MK │ │
└─────────────┘ └─────────────┘ └─────────────┘
MK held in memory only. Never on disk. Rotatable on demand.
The PoC Hardcoding: What It Is and Why It Matters
The current V6 codebase is explicitly a proof of concept, and it contains several hardcoded values that are safe for testing and demonstration but would create real vulnerabilities in production. It is worth being specific about what these are, why they exist, and what would need to change.
PoC Hardcoding Inventory:
┌────────────────────────┬──────────────────────────┬──────────────────────┐
│ What's hardcoded │ Where │ Risk if kept in prod │
├────────────────────────┼──────────────────────────┼──────────────────────┤
│ PBKDF2 salt │ cli.py: │ Two users with same │
│ b"QeltrixV6Salt" │ _mk_from_passphrase() │ passphrase get same │
│ │ │ MK. Rainbow tables │
│ │ │ become possible. │
├────────────────────────┼──────────────────────────┼──────────────────────┤
│ HKDF info strings │ crypto.py: multiple │ Low risk alone, but │
│ e.g. "QeltrixV6-CDK" │ derivation calls │ domain separation │
│ │ │ relies on these │
│ │ │ being unique/secret │
├────────────────────────┼──────────────────────────┼──────────────────────┤
│ PBKDF2 iteration count │ cli.py: 200,000 │ Acceptable today, │
│ │ │ should be tunable │
│ │ │ and higher for HSMs │
├────────────────────────┼──────────────────────────┼──────────────────────┤
│ No MK rotation │ Entire codebase │ Compromised MK = │
│ │ │ all data exposed. │
│ │ │ No re-key mechanism. │
└────────────────────────┴──────────────────────────┴──────────────────────┘
The hardcoded PBKDF2 salt is the most significant issue. A salt's purpose is to make every passphrase derivation unique, so that the same passphrase on two different containers produces two different MKs. With a fixed salt, if an attacker knows a user's passphrase (or can guess common ones), they can precompute a table of passphrase → MK mappings and apply it to any V6 container ever created with that passphrase. The fix is simple: generate a random 32-byte salt per container, store it in the header alongside the encrypted MK, and use it during derivation.
The symmetric MK itself is the second structural concern. AES-256-GCM is a symmetric cipher — the same key encrypts and decrypts. This means every party that can decrypt V6 data can also encrypt it and forge valid blocks. For many use cases (a single operator controlling both gateway and storage) this is fine. For use cases where you want to separate write and read authorization — for example, a sensor that can only encrypt, never decrypt — symmetric encryption is insufficient. RSA or an ECDH-based scheme with separate keys for encryption and decryption roles would be needed.
The Security That Exists Despite These Constraints
It is important to be precise: the PoC hardcoding creates theoretical vulnerabilities, but the system is not simply insecure. Several strong protections remain regardless:
Security Analysis: What Holds Even with PoC Constraints
┌──────────────────────────────────────────────────────────────────┐
│ STRONG regardless of PoC status: │
│ │
│ ● AES-256-GCM / ChaCha20-Poly1305 are cryptographically sound │
│ ● Per-block CDK derivation: compromising one block's key does │
│ not expose any other block's key │
│ ● AEAD authentication: any tampering with any block is │
│ detected and decryption fails with an error │
│ ● V6-C metadata encryption: container structure is opaque │
│ without the MK │
│ ● MK never written to disk in plaintext │
│ │
│ WEAKER due to PoC choices: │
│ │
│ ● Fixed PBKDF2 salt weakens passphrase-to-MK derivation │
│ ● No MK distribution mechanism: operator must solve this │
│ ● Symmetric MK: no separation between encrypt/decrypt roles │
│ ● No key rotation: long-lived MK increases exposure window │
└──────────────────────────────────────────────────────────────────┘
The bottom line: if you control the MK — if it was generated securely and distributed through a trusted channel — the data is strongly protected. The PoC weaknesses are primarily in the convenience layers around the MK (the passphrase-to-key derivation and the lack of a key exchange protocol), not in the core encryption itself.
What Production Would Look Like
Moving V6 from proof of concept to production-grade would require changes in two areas: the key derivation layer and the key distribution layer. The block encryption, block framing, CDK hierarchy, and AEAD authentication are already production-quality in design.
PoC → Production: Required Changes
PoC (current) Production
─────────────────────────────────────────────────────────────
Hardcoded PBKDF2 salt → Random per-container salt,
stored in header
Passphrase via CLI arg → MK via KMS / HSM / ECDH
handshake at startup
No key distribution → ECDH or RSA key encapsulation
between gateway nodes
No key rotation → MK rotation via re-key API;
old containers re-encrypted
on a schedule
Symmetric-only MK → Optional asymmetric wrap:
encrypt-only role vs. full
decrypt role
Single MK per deployment → Per-stream or per-container
MK, managed by KMS
The architecture of V6 — its block model, its CDK hierarchy, its gateway topology — is fully compatible with all of these production hardening steps. The PoC is not a wrong design that needs to be replaced; it is a correct design that needs its key management layer completed.
Summary
Qeltrix V6 is a practical answer to a real problem: how do you store large, sensitive data in a way that is both strongly encrypted and efficiently accessible? By treating encryption not as a one-time transformation but as a structured, seekable container format, V6 makes it feasible to build encrypted video platforms, secure backup systems, privacy-preserving data pipelines, and real-time network encryption gateways — all from a single, unified architecture.
Its block encryption, CDK key hierarchy, and AEAD authentication are production-quality in design. What remains for a real-world deployment is completing the key management layer: replacing the hardcoded PBKDF2 salt with per-container random salts, adding an ECDH or RSA-based MK exchange between gateway nodes, and integrating with a KMS for key lifecycle management. The routing gateway intentionally leaves this to the operator — it is an encryption engine, not a key authority — which means the design is open to being paired with any key distribution mechanism that fits the deployment context.
The combination of a fast C core, a rigorous Python cryptography layer, HTTP Range Request support, and a fully separable key management model makes Qeltrix V6 a strong foundation for the next generation of secure streaming infrastructure.
Explore the project: https://github.com/Qeltrix/Qeltrix-v6
Created by Muhammed Shafin P (@hejhdiss) | License: CC BY-SA 4.0
Top comments (0)