Security Model — Zelen Quantum Encryption

Governed post-quantum object security

Math does not usually fail. Implementations fail.

ZelEn is not just a wrapper around cryptographic algorithms. ZelEn is a complete security architecture for encrypted objects.

It combines post-quantum cryptography, authenticated containers, fail-closed validation, forensic visibility, key lifecycle design, digital signatures, and optional MTE governed decryptability into one system.

Not just protected data. Governed encrypted objects.

ZelEn governed object security vault protecting data flows

The Core ZelEn Invention

ZelEn’s invention is the transformation of encryption from a raw cryptographic operation into a complete governed object lifecycle.

Traditional encryption usually focuses on one thing: encrypt the data. ZelEn goes further.

ZelEn asks how the encrypted object is created, how keys are generated, how the container is structured, how tampering is detected, how inspection works without plaintext exposure, and how the system fails when something is wrong.

It turns post-quantum cryptography into a usable, inspectable, authenticated, fail-closed, containerized object-security system.

Invention 1: The .zelen Governed Container

The .zelen container is one of the central inventions of ZelEn. Most encrypted files become random-looking blobs. They are difficult to inspect, classify, govern, or verify without attempting decryption.

ZELEN magic header Security tier Suite ID Recipient fingerprint KEM ciphertext digest AES-GCM nonce ZELC marker at 0x7D Header authentication tag Encrypted payload Optional ML-DSA signature Optional certificate binding Optional MTE envelope

The .zelen container is not just encrypted data. It is an authenticated post-quantum security object.

ZelEn encrypted container structure with header, payload, signature, and ZELC marker

Invention 2: ZELC Marker at 0x7D

Encrypted files usually look like random noise. DLP cannot classify them easily, SIEM cannot understand them, IDS cannot distinguish them, and incident responders may not know whether the file is legitimate or suspicious random payload.

ZelEn solves this with the ZELC marker at 0x7D. It acts as a structural and forensic anchor inside the .zelen object.

Encrypted objects should be private, but not invisible to authorized security systems. The plaintext remains hidden. The object remains governable.

ZELC anchor at 0x7D enabling DLP, SIEM, and IDS visibility

Invention 3: Fail-Closed Decryption

ZelEn is designed to fail closed. If anything is wrong, ZelEn refuses to release plaintext.

Wrong key Wrong passphrase Bad header Missing ZELC marker Corrupted payload Tampered ciphertext Bad authentication tag Invalid signature Wrong suite Malformed container Invalid MTE reconstruction Wrong .ztau datum Expired policy

ZelEn does not partially decrypt, leak useful attacker details, or expose plaintext before full authentication. Failure becomes silent, generic, and closed.

ZelEn fail-closed path rejecting unauthenticated objects before plaintext release

Invention 4: Complete Post-Quantum Lifecycle

ZelEn is not only an algorithm wrapper. It is a full lifecycle system.

Key generation Public key creation Private key protection File encryption Text encryption File decryption Text decryption Detached signatures Signature verification Container inspection Armor and dearmor Docker execution Web playground usage GitHub Actions lifecycle proof Tamper detection testing

Full GitHub Actions proof for ZelEn lifecycle testing

Invention 5: Clean File Separation

File	Security Role
.zkey	Private key bundle.
.zpub	Public key bundle.
.zcert	Quantum-safe certificate.
.zelen	Encrypted object.
.sig	Detached signature.
.ztau	MTE reconstruction datum.

This separation prevents confusion between private material, public material, signatures, certificates, encrypted objects, and MTE reconstruction authority.

Invention 6: Post-Quantum by Design

ML-KEM-1024Key encapsulation

ML-DSA-87Digital signatures

AES-256-GCMAuthenticated encryption

Argon2idPrivate-key passphrase protection

Domain separationIndependent key schedule outputs

Fail-closed validationNo plaintext before all checks pass

The goal is simple: data encrypted today should remain protected tomorrow.

Invention 7: Misuse-Resistant Design

Common cryptographic mistakes

Nonce reuse
Weak key derivation
Unauthenticated metadata
Wrong key reuse
Bad random number generation
Improper error handling
Signature confusion
Partial decrypt leaks

ZelEn’s safer path

The developer does not manage raw nonce behavior, hand-wire the KEM-to-AEAD pipeline, invent a file format, or guess how signatures bind to containers.

ZelEn wires the dangerous parts internally. That is a security invention.

Primitive misuse replaced by the ZelEn one safe path

Invention 8: MTE Governed Decryptability

Normal encryptionprivate key → decryption attempt

ZelEn MTE.zkey decrypts + .ztau reconstructs + policy governs

MTE separates cryptographic authority from reconstruction authority. The encrypted object must be reconstructed through the authorized τ datum before it can reach the cryptographic decryption stage.

Why MTE Matters for Security

Private-key exposure can be catastrophic in standard encryption. With MTE, the private key alone is insufficient.

No τ. No reconstruction. No plaintext.

MTE makes the encrypted object itself governed. It is not just locked. It must be structurally reconstructed.

MTE Is Not Security by Obscurity

MTE does not replace PQ5, AES-GCM, or require the MTE design to be hidden. The plaintext remains protected by ZelEn’s post-quantum cryptographic core while MTE adds governed object reconstruction around that core.

Correct .zkey Correct passphrase Correct .ztau Correct reconstruction path Correct policy Intact MTE envelope Intact authenticated container

Invention 9: Inspectable Security Without Plaintext Exposure

ZelEn allows encrypted objects to be inspected safely. Security teams can understand the object without decrypting the object.

Container type Suite ID Security tier ZELC marker status Recipient fingerprint Payload length KEM ciphertext length Header authentication presence Signature presence Certificate presence MTE envelope presence

This supports security operations, forensics, DLP, SIEM, compliance, and incident response while preserving confidentiality.

Invention 10: GitHub Actions Proof

ZelEn is not just a claim. ZelEn has a full automated cryptographic lifecycle proof that runs in a clean CI environment from a fresh Docker image.

Key generation works Encryption works Inspection works Signing works Signature verification works Decryption works SHA256 comparison works Text encryption works Text decryption works Armor works Dearmor works Tamper detection works Fail-closed behavior works

What ZelEn Protects Against

Harvest-now-decrypt-later attacks Classical cryptographic obsolescence RSA and ECC quantum risk Primitive misuse Nonce misuse Metadata tampering Header manipulation Ciphertext tampering Signature forgery attempts Partial decrypt leakage Oracle-style error behavior Private-key-only reliance with MTE Forensic blindness Unstructured encrypted blobs Developer misconfiguration Weak cryptographic composition

What ZelEn Never Does

Never releases plaintext before authentication Never treats tampered containers as safe Never exposes raw nonce control to developers Never depends on RSA or ECC for its post-quantum core Never treats encrypted objects as meaningless blobs Never makes the private key the only authority in MTE mode Never requires security teams to be blind to encrypted object structure Never turns cryptography into a guessing game for developers

ZelEn Security Layers

Layer 1: Post-Quantum Key EncapsulationML-KEM-1024 protects the shared secret against quantum-era attacks.

Layer 2: Authenticated EncryptionAES-256-GCM protects the payload and rejects tampering.

Layer 3: Digital SignaturesML-DSA-87 provides quantum-safe signing and verification.

Layer 4: Private-Key WrappingArgon2id protects private key bundles with passphrase-based hardening.

Layer 5: Authenticated Container FormatThe .zelen format binds metadata and encrypted payload into one governed object.

Layer 6: ZELC MarkerThe 0x7D marker gives forensic and structural visibility.

Layer 7: Fail-Closed ValidationNo plaintext is released unless the whole pipeline passes.

Layer 8: MTE Governed ReconstructionThe object must be reconstructed through τ before decryption can proceed.

The Security Philosophy

Do not give developers raw cryptographic danger. Give them a safe object lifecycle. Do not create random encrypted blobs. Create governed encrypted objects. Do not rely on private keys alone. Separate decryption authority from reconstruction authority. Do not fail open. Fail closed. Do not hide encrypted objects from security tools. Make them inspectable without exposing plaintext. Do not invent fragile cryptographic primitives. Build a secure architecture around proven primitives.

The Difference Between ZelEn and Ordinary Encryption

Ordinary encryption

Encrypts data.
Produces ciphertext.
Requires a key.
Often has limited inspection.
Often relies entirely on the private key.
Often leaves governance outside the encrypted object.

ZelEn

Creates a governed encrypted object.
Uses post-quantum primitives.
Authenticates the container.
Supports inspection, signing, and fail-closed validation.
Supports forensic markers and MTE reconstruction authority.
Supports CI proof and developer-ready workflows.

The MTE Difference

Without MTE: ZelEn PQ5 protects ciphertext.

With MTE: ZelEn PQ5 protects ciphertext, and ZelEn MTE governs the object.

MTE does not make the lock stronger by replacing the lock. It changes the object around the lock. The encrypted object must be reconstructed before the lock can even be reached.

Why the Private Key Alone Is Not Enough in MTE

The .zkey The passphrase The .ztau datum The correct MTE envelope The correct reconstruction policy The intact authenticated container The correct PQ5 decryption path

The key opens the lock. The τ datum assembles the locked object. Policy permits the reconstruction. Without τ, the key cannot reach the correct object form.

Security Page Feature Cards

Post-Quantum by Design

ZelEn is built around ML-KEM and ML-DSA, not patched with post-quantum support later.

Governed Object Container

.zelen turns ciphertext into a structured, authenticated, inspectable security object.

ZELC Marker at 0x7D

Encrypted objects remain visible to security tooling without revealing plaintext.

Fail-Closed Decryption

Tampered, malformed, or unauthorized objects release no plaintext.

MTE Governed Decryptability

In MTE mode, the private key alone is not enough. The object must be reconstructed through τ.

Developer-Safe Lifecycle

ZelEn hides dangerous primitive wiring and gives developers a safe encryption path.

CI-Proven Security

The full lifecycle is tested automatically: keys, encryption, signing, verification, decryption, armor, and tamper rejection.

Clean Key Separation

.zkey, .zpub, .zcert, .zelen, .sig, and .ztau each have a clear security role.

Short Security Statement

ZelEn is a governed post-quantum object-security architecture.

It does not merely encrypt data. It creates authenticated encrypted objects that can be inspected, signed, verified, protected against tampering, and optionally governed through MTE reconstruction.

post-quantum cryptography container structure ZELC forensic anchor fail-closed validation developer-safe lifecycle MTE governed decryptability

Security FAQ

What is the main security invention in ZelEn?

The main invention is governed post-quantum object security. ZelEn turns encryption into a complete lifecycle with keys, containers, authentication, inspection, signatures, fail-closed validation, and optional MTE governed reconstruction.

Is ZelEn a new mathematical algorithm?

No. ZelEn uses trusted cryptographic primitives such as ML-KEM, ML-DSA, AES-256-GCM, and Argon2id. The invention is the architecture, container format, lifecycle, and governed object model built around them.

What makes the .zelen container special?

The .zelen container is structured, authenticated, inspectable, and designed for post-quantum object security. It is not just a random ciphertext blob.

What is the ZELC marker?

The ZELC marker is a structural and forensic anchor placed at 0x7D. It helps tools recognize and inspect ZelEn encrypted objects without revealing plaintext.

What does fail-closed mean?

Fail-closed means ZelEn releases no plaintext unless every required validation step succeeds. If anything is wrong, decryption stops.

What does MTE add?

MTE adds governed decryptability. It requires the encrypted object to be reconstructed through the private τ datum before normal decryption can proceed.

Does MTE replace encryption?

No. MTE does not replace PQ5 encryption. It wraps around the encrypted object as a governed structural layer.

Why is private key alone not enough in MTE?

Because the MTE object must be reconstructed through .ztau before the private key can decrypt the canonical encrypted body.

Can security tools inspect ZelEn files?

Yes. ZelEn supports inspection of encrypted containers without exposing plaintext.

What is the simplest way to describe ZelEn security?

ZelEn PQ5 protects ciphertext. ZelEn MTE-PQ5 governs the object.

ZelEn is not just encryption.

ZelEn is the security architecture around encryption.

It gives post-quantum cryptography a container. It gives encrypted data a structure. It gives security teams visibility. It gives developers a safe path. It gives enterprises governed objects.

And with MTE, it changes the meaning of decryption itself: the private key is no longer the whole story. The object must also be reconstructed through τ.