GitHub Repository: https://github.com/Qeltrix/Qeltrix-v6
PyPI:https://pypi.org/project/qeltrix-v6/
[!] Proof-of-concept only. Not for production use without an independent cryptographic audit.
The Problem with Encryption Today
Most encryption tools work the same way they did decades ago: lock a file, and to read any part of it you must decrypt the whole thing first. Want to stream a 4K video from encrypted cloud storage? Download it all. Jump to chapter 12 of an encrypted audiobook? Decrypt everything before it.
Qeltrix V6 breaks this assumption. It is built from the ground up as a live, seekable, encrypted stream - you can jump to any byte offset inside an encrypted file and begin reading immediately, without touching the rest of the data.
Stream-First Block Architecture
Instead of one monolithic blob, V6 splits data into independently encrypted blocks. Each block has its own key, nonce, integrity tag, and metadata. The container behaves like an encrypted database - query exactly what you need.
Traditional:
+----------------------------------------------+
| ONE BIG ENCRYPTED BLOB |
| (must decrypt all to read any part) |
+----------------------------------------------+
Qeltrix V6:
+---------+---------+---------+---------+
| 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
System Architecture
V6 uses a hybrid C + Python design: C handles speed-critical work (block framing, permutation, TCP, seek math), Python handles correctness (AES-256-GCM, ChaCha20-Poly1305, HKDF, SHA-256).
+--------------------------------------------------+
| Qeltrix V6 System |
| +------------------+ +--------------------+ |
| | C Library | | Python Crypto | |
| | * Block framing |<->| * AES-256-GCM | |
| | * Permutation | | * ChaCha20-Poly | |
| | * TCP / HTTP | | * HKDF-SHA256 | |
| | * Seek math | | * MK wrapping | |
| +------------------+ +--------------------+ |
| [ pack/unpack ] [ GatewayServer ] [SeekServer] |
+--------------------------------------------------+
Security Model: Dual-Layer Key Hierarchy
Every block is bound to both its content and its position via a per-block Content Derived Key (CDK):
Passphrase
|
v PBKDF2 / HKDF
Master Key (MK) <- encrypted in container header; never plaintext on disk
|
v HKDF(MK + block_index + data_hash + salt)
Content Derived Key (CDK) <- unique per block AND per position
|
v AES-256-GCM or ChaCha20-Poly1305
Encrypted Block + V6-C Metadata <- tamper-evident AEAD
The V6-C metadata (IV, salt, integrity hash, wrapped CDK) is itself encrypted with the MK. An attacker who intercepts the container learns nothing about its structure without the MK.
HTTP Range Requests: Seek Without Full Download
V6 natively supports HTTP Range Requests. The container footer holds a VFS index mapping original byte ranges to encrypted block positions.
Client SeekServer Container
| | |
| GET / Range:50MB-> | |
|--------------------> | |
| | find blocks for 50MB |
| |---------------------->|
| |<-- only those blocks --|
| | decrypt + slice |
| 206 Partial Content | |
|<---------------------| |
A 20 GB encrypted video serves a seek to minute 18 by decrypting only a few hundred kilobytes.
The Gateway: Encryption Router
The GatewayServer is a TCP encryption router that wraps any data stream in V6 block-encrypted format in real time. No application changes required. It is an encryption engine, not a key authority: the MK must be supplied externally at startup.
What the Gateway Does vs. Does Not Do
[Y] Accepts MK at startup [N] Generates or negotiates MK
[Y] Holds MK in process memory [N] Transmits MK over the wire
[Y] Derives per-block CDKs [N] Stores MK anywhere on disk
[Y] Encrypts / decrypts streams [N] Manages key distribution
[Y] Routes encrypted data [N] Authenticates remote parties
Gateway Deployment Modes
Reflect mode - encrypts and returns the stream to sender (testing / benchmarking):
Client --raw-> GatewayServer --V6 encrypted-> back to Client
Router mode - transparent encryption proxy between source and destination:
Source --raw-> GatewayServer --V6 encrypted-> Destination
Chained mode - multiple gateways, each adding an independent encryption layer:
Source -> GW-A (MK-alpha) -> GW-B (MK-beta) -> Destination
[double encrypted; no single node holds the full decryption capability]
Gateway as a Network Encryption Boundary
TRUSTED ZONE A UNTRUSTED NETWORK TRUSTED ZONE B
+--------------+ +--------------+
| App / DB | | Storage |
+------+-------+ +------+-------+
| |
+------v-------+ V6 encrypted stream +------v-------+
| V6 Gateway | --------------------> | V6 Gateway |
| (Encrypt) | | (Decrypt) |
+--------------+ +--------------+
Network sees only ciphertext. No app changes needed on either side.
Concurrent Architecture
Each connection gets its own worker thread with an independent block counter, CDK chain, and cipher state. The MK is read-only shared memory. Throughput scales linearly with CPU cores.
Full End-to-End Pipeline
PRODUCTION STORAGE (untrusted) CONSUMER
+------------+ +---------------+ +-------------------+
| App/Sensor | | .qltx file | | Media Player / |
+-----+------+ | (cloud / disk)| | Browser / Client |
| raw | sees only | +--------+----------+
v | ciphertext | | HTTP Range
+-----+------+ +-------+-------+ +--------v----------+
| V6 Gateway | ---> | | <----------- | SeekServer |
| (Encrypt) | +-------+ | (Decrypt + Serve) |
+------------+ +-------------------+
MK in memory only MK in memory only
The Master Key: External Distribution Required
The MK lives only in process memory. The container stores an encrypted copy, but that blob is useless without the original key. Every V6 component requires the MK at runtime - it is never self-bootstrapped.
This means the operator is responsible for how two gateway nodes securely share the same MK. Three standard approaches:
ECDH - each side generates a keypair, exchanges only public keys, independently computes the same shared secret. The MK never travels the wire.
Node A Node B
generate (privA, pubA) generate (privB, pubB)
|----- send pubA ----------->|
|<---- send pubB ------------|
MK = HKDF(ECDH(privA, pubB)) MK = HKDF(ECDH(privB, pubA))
[Both arrive at the identical MK without it ever crossing the wire]
RSA Key Encapsulation - encrypt the MK under the recipient's RSA public key, transmit the ciphertext. Only the private key holder recovers it. Requires pre-existing PKI.
KMS - neither node holds the MK long-term. Both request it from Vault / AWS KMS / GCP KMS at startup, authenticated by cloud identity (IAM role, service account). MK is rotatable on demand without touching the codebase.
PoC Hardcoding: Strengths and Weaknesses
The codebase is explicitly a proof of concept. Several values are hardcoded that would need to change for production:
What's hardcoded Risk in production
-----------------------------------------------------------------------
PBKDF2 salt Same passphrase -> same MK on every container.
"QeltrixV6Salt" Enables precomputed rainbow tables.
Fix: random per-container salt stored in header.
No MK distribution Operator must implement ECDH / RSA / KMS.
Symmetric-only MK No write-only vs. read-only role separation.
A decryptor can also forge valid blocks.
No key rotation Compromised MK exposes all data permanently.
What stays strong regardless of PoC status:
AES-256-GCM and ChaCha20-Poly1305 are cryptographically sound. Per-block CDK isolation means one compromised block key exposes nothing else. AEAD authentication catches any tampering immediately. V6-C metadata keeps the container structure opaque without the MK. The MK never touches disk.
The PoC weaknesses are entirely in the key management convenience layer - not in the core encryption.
PoC to Production: Required Changes
PoC (current) Production
-----------------------------------------------------------------------
Hardcoded PBKDF2 salt -> Random per-container salt in header
Passphrase via CLI -> MK from KMS / HSM / ECDH handshake
No key distribution -> ECDH or RSA between gateway nodes
No key rotation -> MK rotation + re-key API
Symmetric-only MK -> Asymmetric wrap for role separation
The block model, CDK hierarchy, gateway topology, and AEAD layer need no changes - they are production-quality in design already.
Use Cases
Secure cloud video streaming - store encrypted video in S3/GCS, serve via HTTP Range Requests. Users seek and play; the storage provider never sees plaintext.
Encrypted CDN - CDN nodes hold only ciphertext. Compromise of a node yields nothing without the MK.
Secure backup with partial restore - seek directly to the blocks for a single file inside a 500 GB archive. No full extraction needed.
Zero-trust microservice mesh - each service pair gets its own MK. Gateway pairs encrypt inter-service traffic; the network fabric sees only V6 ciphertext.
IoT edge encryption - edge gateway encrypts sensor streams before forwarding to cloud. Analytics seeks specific time windows via SeekServer.
Tamper-evident archival - every block carries a SHA-256 hash and AEAD tag. Any bit flip causes authentication failure. Modification is immediately detectable.
Compliance logging - audit logs stream through a V6 gateway. Auditors with the key seek to any time window; nobody else can read them.
Block independence makes V6 inherently parallelizable. Pack and unpack use a ThreadPoolExecutor across all CPU cores. AES-256-GCM is hardware-accelerated via AES-NI on most modern CPUs. ChaCha20-Poly1305 is fast in software, ideal for mobile and IoT without AES-NI. Both are AEAD: every decrypt simultaneously verifies integrity.
Summary
Qeltrix V6 is a correct design with an incomplete key management layer. The block encryption, CDK hierarchy, gateway routing, and AEAD authentication are production-quality. A real deployment additionally needs an MK exchange mechanism (ECDH or RSA handshake, or a KMS), per-container random PBKDF2 salts, and key rotation. The gateway intentionally leaves key distribution to the operator - it is an encryption engine, not a key authority - making it compatible with any key management approach you choose to pair it with.
Explore the project: https://github.com/Qeltrix/Qeltrix-v6
Created by Muhammed Shafin P (@hejhdiss) | License: CC BY-SA 4.0
