Perfect
SecrecyThroughout

One object. One pad. One K3Y. Zero reuse.

ΞNIGMA 3.0 protects data with a one-time XOR cipher. The recovery path is separated through the K3Y. No reusable data keys. No shared recovery object. Customer-controlled from input to storage.

Explore architecture →

XOR operation
non-carrying
reversible per bit

Built on historical roots.
Engineered for timeless principles.

No information
leakage without
the K3Y

MMessage

KOne-time pad

InputM, K

OutputCiphertext

C = M ⊕ K

Cipher equation+

C = M ⊕ K

M = message or plaintext

K = one-time pad

⊕ = XOR operation

M = C ⊕ K

Recovery with the K3Y

K3Y separationRecovery material is isolated and never stored as part of ciphertext.

□

Customer boundaryYou control the runtime, object locations, policy gates, and key systems.

✓

Trust evidenceSigned provenance, integrity records, and auditable redacted metadata.

Zero reuseFresh per-operation Particle material for each new encryption job.

1:1

One object / one padA simple security model expressed directly in the architecture.

Architecture flow+

▧

ObjectPlaintext

→

░

PadOne-time stream

→

⊕

XORM ⊕ K

→

⚿

K3YRecovery path

→

▤

CiphertextStorage

No shared secrets + No cross-object reuse + K3Y separated + Customer-controlled storage

API & system+

POST/v1/job

POST /v1/job
Authorization: Bearer {TOKEN}

{
  "type": "encrypt",
  "source_uri": "az://data/in/audit",
  "destination_uri": "az://data/enc/audit",
  "k3y_uri": "az://trust/audit.k3y",
  "aes_256_gcm_uri": "kv://keys/enigma",
  "codes": ["7842", "11903"],
  "enforce": "tenant:contoso policy:v3"
}

One-time XOR path

Separate K3Y object

Stateless operation

Audit and Trust logs

Verifiable results

View documentation →

Hidden signal // three steps over

Oh Juliett,
where art though?

She was hidden inside ENIGMA the entire time. Shift each letter three positions forward and the name resolves into H Q L J P D. The fourth character is J — JULIETT in the NATO phonetic alphabet — concealed inside the transformed signal. HOTEL opens the transmission. JULIETT is waiting within it. Together they become the rendezvous point: HOTELJULIETT.COM.

HQLJJULIETTPD

“Welcome, Juliett. Enigma is here.”

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Source

E N I G M A

+ 3 shift

H Q L J P D

Phonetic signal

HOTEL QUEBEC LIMA JULIETT PAPA DELTA

HOTELJULIETT.COM

ΞNIGMA 3.0 // ORIGIN // THE MACHINE BEFORE THE PLATFORM

HISTORICAL ORIGIN // MECHANIZED SECRECY

The machine that made secrecy move.

The historical Enigma was an electro-mechanical rotor cipher machine. A keypress passed through a configurable electrical path—plugboard, rotating wheels, and reflector—then lit a different letter. Because the rotors moved after each keypress, the substitution changed continuously instead of remaining fixed.

SIMPLIFIED SIGNAL PATH

A Keypress Operator input

→

↔ Plugboard Pair substitution

→

I II III Rotors State changes on every keypress

→

↩ Reflector Returns the signal

→

Q Lampboard Encrypted output

The machine did not merely replace letters. It transformed them through a changing internal state.

What it was

A portable machine for turning typed messages into changing letter substitutions. Commercial versions appeared first; later variants were adapted for government and military communications.

What it meant

Enigma made cryptography operational. Secrecy became a repeatable machine process governed by configuration, daily settings, key discipline, and procedure—not simply by a clever alphabet.

What we inherit

ΞNIGMA 3.0 is not the historical rotor cipher. It inherits the deeper idea: a machine that transforms a message under controlled secret state, with the recovery path protected as deliberately as the ciphertext.

THEN Moving rotors changed the alphabet.

→

NOW M ⊕ K changes the bytes; K3Y protects the way back.

THE ORIGINAL ENIGMA made secrecy mechanical. ΞNIGMA 3.0 makes separation operational.

ΞNIGMA 3.0 // SECTION 00 // PERFORMANCE

Measured cryptographic throughput.

Azure Cobalt ARM 100 benchmark profile with the full FIPS core, K3Y seal path, and optional post-quantum adjuncts represented in the original platform content.

16 MB CHUNK
10.38 GiB PAYLOAD
CUSTOMER BOUNDARY

2 vCPU — 1.56 GiB/s enc · 1.46 GiB/s dec › 4 vCPU — 3.59 GiB/s enc · 3.31 GiB/s dec › 8 vCPU — 6.76 GiB/s enc · 7.92 GiB/s dec › 10 vCPU — 8.14 GiB/s enc · 7.57 GiB/s dec › 16 MB chunk · Azure Cobalt ARM 100 · FIPS 140-3 + PQC full stack › 2 vCPU — 1.56 GiB/s enc · 1.46 GiB/s dec › 4 vCPU — 3.59 GiB/s enc · 3.31 GiB/s dec › 8 vCPU — 6.76 GiB/s enc · 7.92 GiB/s dec › 10 vCPU — 8.14 GiB/s enc · 7.57 GiB/s dec › 16 MB chunk · Azure Cobalt ARM 100 · FIPS 140-3 + PQC full stack

Azure Cobalt ARM 100 · 16 MB chunk · 10.38 GiB payload FIPS 140-3 + PQC full stack

8.14GiB/s

encrypt 10 vCPU

7.92GiB/s

decrypt 8 vCPU

~6 ms

K3Y seal

Encrypt GiB/s — linear 2→8 vCPU

2 vCPU

1.56

4 vCPU

3.59

8 vCPU

6.76

10 vCPU

8.14

Write-bound at 8+ vCPU · blob egress ~0.47–0.57 GiB/s ceiling · +9 MB RSS / job

Full Key Stack

FIPS 140-3

AES-256-GCM

ECDSA P-384

HKDF-SHA-384

Post-Quantum

ML-KEM-768

ML-DSA-65

SLH-DSA-128s

ITS Layer

Particle XOR

K3Y capsule

OTP codes

ΞNIGMA 3.0 // SECTION 01 // OPERATING MODEL

Single-purpose cryptographic system

One job.Zero ambiguity.

ΞNIGMA 3.0 does one thing extremely well: it moves encryption work into the customer boundary, keeps payloads out of the control plane, and separates the K3Y Trust path from the ciphertext it protects.

Control plane≠Customer data plane

01 // Coordinate

You send pointers.

Blob Storage URIs and Key Vault references form compact, auditable job manifests. Customer payloads stay out of the control plane while ΞNIGMA reads and writes the raw bytes directly inside the customer boundary.

Blob URIsVault refsAuditable manifest

02 // Transform

We lock the bytes.

The service operates on the actual byte stream in-boundary with a one-time Particle XOR layer, AES-256-GCM sealing, GMAC integrity, ECDSA-P384 signatures, and optional Kyber-768, ML-DSA, and SLH-DSA adjuncts.

Particle XORGMACP-384PQC adjuncts

03 // Provision

Keygen forges the stack.

POST /v1/keygen provisions the AES, signing, and post-quantum references consumed by the direct encrypt and decrypt paths, then returns stable vault URIs for operators and applications.

AES referenceSigning keysPQC materialStable URIs

Input: referencesOutput: ciphertext + separate K3Y Trust path

ΞNIGMA 3.0 // SECTION 02 // ARCHITECTURE

Azure Section

Azure deployment surface.
Primary cloud path today.

ΞNIGMA 3.0 for Cloud can be described generically, but Azure is the first-class operational surface in this build. The service deploys inside the customer subscription, uses managed identity instead of shared secrets, reads from Blob Storage, resolves Key Vault references, encrypts or decrypts in-boundary, and writes ciphertext plus K3Y back to customer-controlled locations.

Blob Storage

Input, output, backlog, encrypted objects, and optional K3Y blob locations.

Key Vault

AES session keys, ECDSA keys, Kyber public key material, and future PQC key references.

Managed Identity

Least-privilege read/write and sign/unwrap authorization without handing ΞNIGMA 3.0 raw account secrets.

Marketplace / entitlement

Boot-time entitlement checks can gate protected cryptographic operations before workloads are accepted.

Customer App
   ↓ REST + bearer token
ΞNIGMA 3.0 Service inside customer VNet / AKS / VM / Container Apps
   ├── Read source_uri        → Azure Blob Storage
   ├── Resolve key URIs      → Azure Key Vault / HSM-backed ES384
   ├── Encrypt / decrypt     → Particle XOR + FIPS + optional PQC
   ├── Emit Trust metadata   → K3Y capsule + unwrap JSON
   └── Write artifacts       → Blob + Key Vault / storage URI

ΞNIGMA 3.0 // SECTION 03 // ITS

Particle XOR Layer — Not AES-at-Rest

The customer byte stream is transformed by a one-time, per-operation Particle XOR layer — not a block cipher applied directly to plaintext. AES-256-GCM is used to seal the K3Y Trust capsule, not as the primary byte cipher. A 384-bit FIPS DRBG seed drives the keystream, is consumed once, and is sealed separately from the ciphertext in K3Y, protected by FIPS and PQC controls.

OTP-InspiredParticle Engine XOR Layer

At encrypt time, ΞNIGMA 3.0 creates a ParticleKey — six 64-bit words, 48 bytes total, 384 bits — drawn from the SP 800-90A FIPS DRBG. HKDF-SHA-384 expands it into a position-addressable keystream through ParticleEngine. Each 128-byte block is a deterministic, non-repeating function of seed and block index.

One-time key per operation. The 384-bit seed is fresh for every encrypt call; it is never persisted or reused outside the sealed Trust capsule.
Keystream never exposed. Raw keystream bytes are never written to output; only XOR ciphertext is emitted.
Parallel without state sharing. Position addressability lets workers encrypt disjoint chunks without coordination or reuse risk.
Seed committed into Trust. The arng_key seed is sealed with AES-256-GCM inside K3Y, unavailable without the capsule and session key path.

Security Guarantee

ΞNIGMA 3.0's ciphertext layer is designed to remove the block-cipher structure normally present in AES-at-rest ciphertext. The only practical path to recovery is the sealed one-time Particle seed, which is separated from the ciphertext and protected through K3Y, AES-256-GCM, and PQC wrapping. An adversary holding only the ciphertext blob has no structured target to attack.

// Seeded from FIPS DRBG — 6×u64

ParticleKey { x, y, z, r, p, t } ← 384-bit one-time seed

// HKDF-SHA-384 schedule derivation

kx, ky, kz, ktau ← domain-separated subkeys

// Per-block output

block[i] = mix64(seed, kx/ky/kz/ktau, step=i, tau)

ciphertext[i] = plaintext[i] XOR block[i]

The design keeps the raw seed, keystream, private keys, and plaintext out of customer-visible artifacts. Only ciphertext, K3Y, and redacted/authorized Trust outputs are emitted.

ΞNIGMA 3.0 // SECTION 04 // ITS OTP

OTP-Inspired · Structure-Minimized Byte Layer PQC-Protected Seed & Trust Path

The byte layer is not AES-at-rest.
One-time Particle XOR. Seed sealed in K3Y.

Most at-rest systems encrypt bytes with AES and then manage AES keys. ΞNIGMA 3.0 is different: the customer byte stream is transformed by a one-time Particle XOR layer. AES-256-GCM is used to seal the K3Y Trust capsule, not as the primary byte cipher. ML-KEM/Kyber and PQ signature adjuncts protect the future survivability of the seed, Trust, and authentication path. The ciphertext layer is designed to minimize exploitable structure — the only path to recovery is the sealed one-time seed, separated from the ciphertext and protected by FIPS and PQC controls.

📜

True One-Time Pad

Shannon 1949 · Perfect Secrecy

A true OTP XORs plaintext with a uniformly random key of identical length, used exactly once and never reused. Claude Shannon proved it provides perfect secrecy: ciphertext is statistically independent of plaintext regardless of computing power.

Unconditionally secure — no computer can break it
Key must equal plaintext length — impractical at scale
Key must be pre-shared via separate secure channel
Any reuse catastrophically leaks plaintext

// Vernam 1919 / Shannon 1949

C = M ⊕ K where |K| = |M|

K is uniform random, used once

H(M | C) = H(M) ← perfect

💻

Computational Security

AES · RSA · ECDSA · Standard TLS

Most ciphers (including AES in a standard block mode) are computationally secure: ciphertext has structure an attacker could exploit given enough compute. Security is defined by the hardness of a mathematical problem — factoring, discrete log, lattice problems.

Practical key sizes — same key can encrypt many messages
FIPS-validated, auditable, well-studied
Ciphertext carries mathematical structure
Quantum computers (Grover, Shor) reduce effective security

// Computational assumption

Security ≡ hardness of problem P

AES-256: Grover → ~2¹²⁸ quantum ops

Ciphertext has algebraic structure

⚡

ΞNIGMA 3.0 Particle XOR

Seeded OTP-class · Per-session

ΞNIGMA 3.0 uses an OTP-inspired, structure-minimized construction: a 384-bit one-time seed expands via HKDF-SHA-384 into a position-addressable keystream of the exact plaintext length, XOR'd in one pass, seed never reused. This is not a formal Shannon OTP — the keystream is derived from a short seed, not drawn from message-length uniform randomness — but the ciphertext is designed to carry minimal exploitable structure, with security resting on seed confidentiality rather than algorithmic hardness.

Structure-minimized ciphertext — no block-cipher algebraic shadow
Per-session 384-bit seed, never reused across operations
Practical: seed is tiny; keystream expands to plaintext length
Seed sealed in K3Y — separate from ciphertext

// ΞNIGMA 3.0 Particle engine

seed ← FIPS DRBG (384 bits, one-time)

ks[i] = HKDF-SHA-384(seed, i)

C[i] = M[i] ⊕ ks[i]

C is seed-derived, not AES-structure-derived ✓

Why quantum computers cannot attack ΞNIGMA 3.0 ciphertext

Quantum algorithms target mathematical structure. Particle XOR ciphertext minimizes that surface.

Shor's algorithm breaks RSA and ECDSA because their ciphertext carries the mathematical relationship between a known public key and secret private key — a structured problem amenable to quantum period-finding. Grover's algorithm speeds up brute-force key search, halving effective AES bit-strength.

Particle XOR ciphertext does not carry AES block-cipher structure. The security rests on seed confidentiality: an attacker holding only ciphertext cannot reconstruct the keystream without the 384-bit seed, which is sealed in K3Y under AES-256-GCM and optionally ML-KEM-768. Attacking the ciphertext bytes directly yields no algebraic foothold for Shor or Grover — there is no key schedule, no round structure, and no known period to exploit.

Quantum attack surface per layer

XOR ciphertext bytes No structure · quantum-irrelevant

AES-256-GCM (K3Y seal) Grover → ~2¹²⁸ ops · remains strong

ECDSA-P384 (signature) Shor → broken · mitigated by ML-DSA

ML-KEM-768 (K3Y wrap) Module-LWE · quantum-resistant

ML-DSA-65 + SLH-DSA (signatures) Lattice + hash · quantum-resistant

The key is where quantum risk lives. So we seal it with PQC.

The only thing a quantum computer could theoretically target in ΞNIGMA 3.0 is the K3Y capsule — the sealed container holding the 384-bit Particle seed. That's where Kyber-768 / ML-KEM-768 applies: the entire K3Y is KEM-wrapped with a Module-LWE key-encapsulation scheme that has no known quantum attack.

The signatures (ECDSA-P384) are the only classically vulnerable element in a harvest-now-decrypt-later scenario. ML-DSA and SLH-DSA adjuncts add post-quantum authentication so the Trust capsule itself remains verifiable under a post-quantum threat model.

Threat model: harvest-now-decrypt-later (HNDL)

Attacker stores ciphertext today, decrypts later

XOR ciphertext: useless without the seed. Seed is sealed in K3Y, which is separately controlled.

Attacker also stores the K3Y capsule

K3Y is AES-256-GCM sealed (128-bit quantum floor via Grover) and optionally ML-KEM-768 wrapped — no known quantum attack.

Result: full-stack HNDL resistance

Ciphertext is structureless. K3Y is PQC-wrapped. Signatures are PQC-covered. The harvest attack has no exploitable entry point.

Why not just use AES-CTR everywhere?

AES-CTR is an excellent FIPS cipher — ΞNIGMA 3.0 uses AES-256-GCM to seal K3Y precisely because it is well-understood and FIPS-validated. The distinction is where each algorithm applies: AES-GCM is used for authenticated key wrapping (the K3Y capsule), not as the primary byte cipher over the customer data.

Thales, IBM, Fortanix, Entrust, and cloud KMS help organizations manage conventional AES encryption estates. ΞNIGMA 3.0 adds a separate protected-byte layer: one-time Particle XOR over the data, K3Y separation for the seed and Trust object, and PQC protection around the long-term recovery path. It is a different architectural choice, not a replacement for standard key management.

Defense in depth: why both layers?

The Particle XOR layer produces structure-minimized ciphertext whose recovery path runs entirely through the sealed one-time seed. The AES-256-GCM seal on K3Y provides authenticated key wrapping with a proven FIPS primitive. The PQC KEM wrap (ML-KEM-768) adds a second key-protection layer under lattice assumptions. The signatures (ECDSA-P384, ML-DSA, SLH-DSA) provide Trust provenance under classical, lattice, and hash-based assumptions independently.

No single algorithm failure compromises the full system. The XOR ciphertext remains structureless regardless of what happens to any key-wrapping or signing algorithm.

// Layered security property

Break(XOR layer) requires seed

Break(K3Y seal) requires AES key + PQC key

Break(Trust auth) requires ECDSA + ML-DSA + SLH-DSA

All three must fail simultaneously ✗

ΞNIGMA 3.0 // SECTION 05 // NO KEY REUSE

No K3Y Reuse · Ever Harvest-Now-Decrypt-Later Closed

Every encrypt operation gets a
brand new K3Y. Zero exceptions.

The single most catastrophic failure mode for any OTP-class or XOR cipher is keystream reuse. If the same key is ever used twice, an attacker who holds both ciphertexts can XOR them together and eliminate the keystream entirely — recovering a direct relationship between the two plaintexts with no cryptographic work at all. ΞNIGMA 3.0 makes this structurally impossible.

Why OTP reuse is catastrophic

Two ciphertexts, same key = plaintext exposed

When the same keystream K encrypts two messages M1 and M2, an attacker who captures both ciphertexts can trivially cancel out the key:

// Two encryptions, same seed (catastrophic)

C1 = M1 ⊕ K

C2 = M2 ⊕ K

C1 ⊕ C2 = M1 ⊕ M2

// Key eliminated entirely — no crypto needed

The attacker now holds the XOR of the two plaintexts. With any knowledge of the probable content of either message — language patterns, file headers, known fields — both plaintexts can often be recovered with basic statistical analysis. This is exactly how historical OTP reuse attacks (VENONA, two-time pad attacks) broke real-world systems.

Real-world reuse attacks

VENONA (1940s–50s): Soviet OTP messages were partially reused under wartime production pressure, enabling NSA to recover thousands of plaintexts over decades.

WEP (802.11): RC4 IV reuse allowed passive attackers to recover plaintext and then the key within hours using only captured packets.

CTR mode nonce reuse: AES-CTR with a repeated nonce leaks the XOR of plaintexts and breaks GCM authentication entirely if combined with GHASH forgery.

How ΞNIGMA 3.0 prevents reuse structurally

The seed is born, used once, and sealed. It cannot escape.

ΞNIGMA 3.0 generates a fresh 384-bit Particle seed from the FIPS SP 800-90A DRBG at the start of every single encrypt operation. The seed is:

Never stored in plaintext anywhere

The seed is immediately used to drive HKDF-SHA-384 expansion. Raw seed bytes are never written to disk, log, or memory outside the active encrypt context.

Sealed inside K3Y under AES-256-GCM immediately

The arng_key field in the Trust CBOR payload is encrypted by the caller-supplied session key. No party, including ΞNIGMA 3.0 itself, can read it back without the session key.

Bound to exactly one trust_id

Every K3Y capsule carries a unique trust_id UUID and qscc_id. The seed, GMAC chain, and signature all commit to this ID. Replaying a K3Y into a different context fails AES-GCM AAD verification.

No ΞNIGMA 3.0 component holds a key registry

The service is stateless between jobs. There is no database of issued seeds to compromise, no session store to exfiltrate, no long-lived material that spans operations.

// Structural guarantee per encrypt()

seed = DRBG.generate(48 bytes) ← fresh, never reused

trust_id = UUID::new_v4() ← unique capsule identity

arng_key sealed in K3Y[trust_id] ← inaccessible without session key

// No seed is ever issued twice

Harvest-Now-Decrypt-Later: why it fails against ΞNIGMA 3.0

HNDL is the threat where an adversary records encrypted traffic today and waits for a future quantum computer to break the key. Against most systems this is a genuine long-term risk. Against ΞNIGMA 3.0 it has no viable attack path — at any point in the attack timeline.

What attacker harvests	What they need to decrypt	Classical attack	Quantum attack
XOR ciphertext blob	The 384-bit seed that produced the keystream	No structure to attack	No structure to attack
K3Y capsule (no session key)	AES-256-GCM session key to unseal it	2²⁵⁶ brute force	~2¹²⁸ via Grover — still infeasible
K3Y capsule (with session key)	ML-KEM-768 private key to unwrap (if PQC enabled)	Module-LWE: no known attack	Module-LWE: no known quantum attack
Two ciphertexts, same file	Same seed reused (different K3Y per encrypt)	Impossible — new seed per operation	Impossible — new seed per operation
Trust signature (ECDSA-P384)	Forge a signature (does not give plaintext)	ECDLP: classically hard	Shor: broken — mitigated by ML-DSA + SLH-DSA

Note: forging an ECDSA signature on a Trust capsule does not grant access to plaintext or the seed — it only affects authenticity attestation, which is separately covered by ML-DSA and SLH-DSA adjuncts.

1 : 1

One seed per encrypt job

Every call to encrypt() generates exactly one 384-bit DRBG seed. It is consumed by that operation and never issued again under any circumstance.

∅

Zero persistent key state

ΞNIGMA 3.0 holds no key material between jobs. There is no in-memory key store, no issued-seed registry, and no shared state that survives a job completion or service restart.

∞

Unlimited distinct operations

Because each seed is independently drawn from FIPS DRBG with 384 bits of entropy, the probability of any two seeds colliding across all operations ever run is negligible by the birthday bound at that size.

ΞNIGMA 3.0 // SECTION 06 // STACK

FIPS Cryptographic Stack

FIPS operations are handled by AWS-LC through aws_lc_rs, with runtime posture asserted via AWS_LC_RUST_FIPS=1 before protected operations proceed.

FIPS 140-3

Symmetric — AES-256-GCM

Seals the Trust capsule. The 32-byte session key is caller-supplied and not generated or persisted by ΞNIGMA 3.0. AES-GCM AAD binds codes and enforce values.

AES_256_GCM · aws_lc_rs

GMAC

Streaming Integrity

Per-chunk GMAC tags authenticate XOR ciphertext. A dedicated MAC key is derived with HKDF-SHA-256 from the session key and Trust ID.

HKDF-SHA-256 · ΞNIGMA 3.0|GMAC|KEY|v1

HKDF

Key Derivation

HKDF-SHA-384 expands Particle seed, HKDF-SHA-256 derives GMAC key, and HKDF-SHA-512 derives Kyber KEK from KEM shared secret.

SHA-256 · SHA-384 · SHA-512

Signature

ECDSA-P384

Every Trust capsule is signed with ECDSA P-384 / SHA-384. Optional secondary ES384 provides dual-signature coverage. Azure Key Vault can keep private signing HSM-side.

ECDSA_P384_SHA384_ASN1

DRBG

Randomness

aws_lc_rs::rand::SystemRandom backs Particle seed, nonce generation, and key generation. No external raw entropy is used directly.

SP 800-90A CTR_DRBG

Gate / AAD

Policy Binding

Access codes and enforce payloads are SHA-256 digested and committed as associated data. Wrong values cause AES-GCM authentication failure.

codes_digest · enforce_digest · aad_v1()

ΞNIGMA 3.0 // SECTION 07 // PQC

Post-Quantum Cryptography Adjunct

The PQC layer is an opt-in adjunct under the pqc-adjunct feature. It adds three independent post-quantum algorithms on top of the FIPS core. A failure in one algorithm does not automatically compromise the others or the underlying XOR layer.

PQC operations use liboqs through the oqs crate and are marked non-FIPS in Trust when applicable, while the FIPS core remains AWS-LC based.

ML-KEM

Kyber-768 / ML-KEM-768

Wraps the entire K3Y capsule. ΞNIGMA 3.0 encapsulates a shared secret to the recipient public key, derives a 256-bit KEK via HKDF-SHA-512, AES-256-GCM-wraps the K3Y, and prepends a K1 marker.

• FIPS 203 / Module-LWE family
• Protects K3Y confidentiality against harvest-now-decrypt-later risk
• No raw KEM output used directly

ML-DSA

CRYSTALS-Dilithium

Optionally signs the Trust capsule bytes and appends an S1 block. Decrypt/unwrap verifies the signature before returning payload material or Trust output.

• FIPS 204 / Module-LWE family
• Post-quantum authentication of Trust origin
• Stacks with ECDSA-P384

SLH-DSA

SPHINCS+ / SLH-DSA

Optionally adds a stateless hash-based signature as an S2 block. It is independent from lattice assumptions and useful as a conservative second PQ signature layer.

• FIPS 205 / hash-based
• Stateless signing model
• Conservative security assumption

Algorithm Summary

Algorithm	Standard	Role	Assumption	Feature
Kyber-768 / ML-KEM-768	NIST FIPS 203	K3Y wrap	Module-LWE	`pqc-adjunct`
ML-DSA / Dilithium	NIST FIPS 204	Trust signature S1	Module-LWE	`pqc-adjunct`
SLH-DSA / SPHINCS+	NIST FIPS 205	Trust signature S2	Hash collision resistance	`pqc-adjunct`
ECDSA-P384	FIPS 186-5 / AWS-LC	Primary Trust signature	ECDLP	Always on

Kyber-768 / ML-KEM-768

K3Y wrap

Standard

NIST FIPS 203

Assumption

Module-LWE

Feature gate: pqc-adjunct

ML-DSA / Dilithium

Trust signature S1

Standard

NIST FIPS 204

Assumption

Module-LWE

Feature gate: pqc-adjunct

SLH-DSA / SPHINCS+

Trust signature S2

Standard

NIST FIPS 205

Assumption

Hash collision resistance

Feature gate: pqc-adjunct

ECDSA-P384

Always on

Standard

FIPS 186-5 / AWS-LC

Assumption

ECDLP

Role: primary Trust signature

ΞNIGMA 3.0 // SECTION 08 // K3Y

K3Y Trust Capsule

K3Y is the authenticated, encrypted capsule carrying the Particle seed and cryptographic provenance for a ciphertext. It is stored and transmitted separately from the ciphertext, so possession of both artifacts and valid gates is required to decrypt.

codes

Multi-party authorization or break-glass codes; hashed into Trust and AAD.

enforce

Hard policy binding such as tenant, policy, or environment values.

info

Audit and telemetry metadata emitted for SIEM, QSCC, and unwrap visibility.

K3Y INTERNAL RECORD // CBOR

Trust Payload

The encrypted operating record behind every K3Y. It binds the one-time seed, verification keys, policy commitments, ciphertext integrity, and operation telemetry into one signed capsule.

SEALED BEFORE OUTPUT AES-256-GCM · AAD BOUND

CORE RECOVERY SECRET arng_key

48-byte, one-time Particle seed. This is the compact recovery material that regenerates the exact position-addressable K stream for the ciphertext.

CLASSICAL IDENTITY pk_primary / pk_secondary

Primary and optional secondary ECDSA-P384 public keys used to verify Trust provenance and dual-attestation paths.

POST-QUANTUM IDENTITY pqc_kem_pub pqc_sig_pub / pqc_slh_sig_pub

Optional Kyber-768 recovery key plus ML-DSA and SLH-DSA verification keys when the PQC adjunct stack is enabled.

POLICY COMMITMENTS codes_digest / enforce_digest

SHA-256 commitments that bind ordered authorization codes and required enforcement policy into the capsule without exposing the original values.

CIPHERTEXT INTEGRITY ct_gmac_chunks

Per-chunk GMAC tags over ciphertext. Decrypt verifies the stream chunk by chunk before releasing recovered plaintext.

MEASURED EXECUTION qscc_*

Bytes processed, start and end timestamps, wall time, throughput, integrity timing, and execution telemetry for the operation.

OPERATION IDENTITY trust_id / qscc_id / timestamp_ns

Unique identifiers and nanosecond timing that anchor the capsule to one encryption event, one Trust record, and one measurable execution trail.

INTERNAL STATE→ CBOR→ SIGN→ AES-GCM SEAL→ K3Y

Separation of K3Y and Ciphertext

Ciphertext and K3Y are separate binary blobs. In Azure, ciphertext can live in Blob Storage while K3Y lives in Key Vault or a restricted storage path. An attacker with only one artifact cannot reconstruct plaintext.

Ciphertext

Azure Blob Storage

XOR payload bytes

K3Y

Key Vault / restricted URI

AES-GCM sealed seed + Trust

Seal, Wrap, Sign

AES-GCM Trust bytes are sealed with the session key and AAD from codes/enforce.

K1 Optional Kyber KEM wrap protects the entire sealed K3Y.

S1 / S2 Optional ML-DSA and SLH-DSA signatures are appended and verified atomically.

GMAC Chain

Per-chunk 128-bit tags are written into Trust and verified chunk-by-chunk on decrypt. A SHA-256 digest of all tags provides a compact integrity summary.

gmac_key = HKDF(session_key, trust_id, "ΞNIGMA 3.0|GMAC|KEY|v1")

nonce[i] = trust_prefix_u64 || chunk_index_u32

tag[i] = AES-256-GCM-GMAC(gmac_key, nonce[i], chunk[i])

tag_digest = SHA-256(tag[0] || tag[1] || … || tag[n])

ΞNIGMA 3.0 // SECTION 09 // FLOW

End-to-End Encryption Flow

Layers applied during encrypt(). Each layer has a separate purpose: payload confidentiality, streaming integrity, Trust sealing, optional PQC KEM wrap, and optional PQ signatures.

Particle XOROne-time XOR over plaintext bytes

384-bit FIPS DRBG seed → HKDF-SHA-384 schedule → position-addressable 128-byte blocks → XOR over plaintext. Emits structure-minimized ciphertext. Seed committed as arng_key.

FIPS LayerGMAC streaming integrity

Per-chunk AES-GMAC tags computed over XOR ciphertext using an HKDF-derived MAC key. Tags and summary digest are committed to Trust.

FIPS LayerTrust assembly and AES-GCM seal

Trust structure is serialized, signed with ECDSA-P384, and sealed with AES-256-GCM using session key and AAD(codes,enforce). Output is K3Y.

PQC OptionalKyber-768 KEM wrap

If provided, recipient Kyber public key encapsulates a shared secret. HKDF-SHA-512 derives KEK; AES-256-GCM wraps K3Y and prepends K1.

PQC OptionalML-DSA and SLH-DSA signature append

API Reference

Nine endpoints. Each cryptographic operation works on bytes already staged at Azure Blob and Key Vault URIs — the control plane never handles payload data inline.

Base URL

https://{your-enigma-host}/

Deployed inside your VNet, AKS cluster, VM, or Container Apps. The hostname is entirely customer-controlled — ΞNIGMA 3.0 has no shared infrastructure.

Authentication

Authorization: Bearer $TOKEN

Bearer token set at deploy time, or JWT when the jwt-auth feature is enabled. All routes require a valid token.

Job Operations

POST /v1/job
GET /v1/job/{id}

Cryptographic Operations

POST /v1/encrypt
POST /v1/decrypt
POST /v1/keygen
POST /v1/unwrap

Diagnostics

GET /v1/health
POST /v1/test
POST /v1/kat

Job Operations

POST /v1/job Async · 202 Accepted

Submit an encrypt or decrypt job. Returns immediately with a job_id and a status_uri to poll. The operation runs asynchronously inside the cloud boundary; results and Trust metadata appear on the status record when the job completes.

Request Body · application/json fields applied in stack order ↓

Job

type required "encrypt" or "decrypt". Determines whether bytes are protected or restored. Inferred from the URL path on /v1/encrypt and /v1/decrypt.

source_uri required Blob URI ΞNIGMA 3.0 reads input bytes from — plaintext for encrypt, ciphertext for decrypt. Format: az://container/path.

destination_uri required Blob URI ΞNIGMA 3.0 writes output bytes to — ciphertext for encrypt, plaintext for decrypt.

k3y_uri cond Concrete Blob location for the K3Y capsule. On encrypt, ΞNIGMA 3.0 writes the capsule to this path; on decrypt, ΞNIGMA 3.0 reads it back from the same path.

id optional Stable identifier for this payload — embedded in Trust metadata and the job record for audit and correlation.

codes optional Array of string access codes committed as SHA-256 AAD bound into the AES-GCM seal. Wrong values cause authentication failure at decrypt — no partial output.

enforce optional Policy enforcement string committed as AAD. Must match exactly at decrypt time. e.g. "tenant:contoso policy:finance-v3".

info optional Arbitrary metadata string embedded in Trust for audit, SIEM, and provenance tracing.

FIPS 140-3 Layer AES-256-GCM encryption · ECDSA P-384 signatures · HKDF-SHA-384 derivation

aes_256_gcm_uri

required FIPS · enc Key Vault secret URI for the 32-byte AES-256-GCM session key that seals and unseals the K3Y Trust capsule. Format: kv://vault/secret-name.

ecdsa_p384_uri optional FIPS · sig ECDSA-P384 signing key URI. kv:// for a PEM-encoded secret; kvk:// for a Key Vault managed key that signs server-side without key export. Signs the Trust capsule on encrypt; verified on decrypt.

ecdsa_p384_secondary_uri optional FIPS · sig ×2 Secondary ECDSA-P384 key for dual-signature coverage on the Trust capsule. Both signatures must verify on decrypt.

expected_ecdsa_pk_sha256_hex optional FIPS · verify SHA-256 hex of the expected ECDSA-P384 signer public key. Verified on decrypt before plaintext bytes are written. Preferred over the full-key form.

expected_ecdsa_pk_hex optional FIPS · verify Full hex-encoded ECDSA-P384 public key. Alternative to the SHA-256 digest form — provide one or the other, not both.

Post-Quantum Layer ML-KEM-768 key encapsulation · ML-DSA-65 lattice signatures · SLH-DSA-128s hash-based signatures

kyber_768_uri optional PQC · KEM ML-KEM-768 (FIPS 203) public key URI for encrypt — wraps the K3Y seed; private key URI for decrypt — unwraps. Requires pqc-adjunct build feature.

ml_dsa_uri optional PQC · sig ML-DSA-65 (FIPS 204) signing key URI for encrypt; verification key for decrypt. Lattice-based signature over the full Trust capsule.

slh_dsa optional PQC · sig SLH-DSA-128s (FIPS 205) signing key URI for encrypt; verification key for decrypt. Stateless hash-based signature — no statefulness requirement, strongest post-quantum guarantee.

Response · 202 Accepted

{
  "job_id": "job-audit-q2",
  "status": "accepted",
  "status_uri": "/v1/job/job-audit-q2"
}

When the encrypt job finishes, GET /v1/job/{id} returns the Blob k3y_uri to use for later decrypt or unwrap.

Example

curl "$BASE_URL/v1/job" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "encrypt",
    "source_uri": "az://data/in/audit",
    "destination_uri": "az://data/enc/audit",
    "k3y_uri": "az://trust/audit.k3y",
    "aes_256_gcm_uri": "kv://keys/enigma",
    "codes": ["7842","11903"],
    "enforce": "tenant:contoso policy:v3"
  }'

GET /v1/job/{id} Poll · 200 OK

Fetch the current state of an async job. Poll until status is "succeeded" or "failed". Trust metadata and the K3Y URI appear on success; error_code and error_label appear on failure.

Path Parameter

id required The job_id returned by POST /v1/job.

Response · 200 OK

{
  "job_id": "job-audit-q2",
  "status": "succeeded",
  "k3y_uri": "az://trust/audit.k3y",
  "trust": { "trust_id": "...", "fips": true },
  "error": null
}

Cryptographic Operations

POST /v1/encrypt Sync · 200 OK

Synchronous direct encrypt. Reads source bytes from source_uri, applies the Particle XOR keystream and FIPS cryptographic sealing entirely in-boundary, writes ciphertext bytes to destination_uri, writes the K3Y capsule to the Blob path in k3y_uri, and returns Trust JSON inline. The core stack is FIPS; PQC is an optional adjunct that rides alongside it. Accepts the same fields as POST /v1/job — the type field is inferred from the path.

Request Body · grouped by stack order

Inputs And Commitments

source_uri required Blob URI of the plaintext bytes to encrypt. This is the data plane input before any stack-specific keying is applied.

destination_uri required Blob URI where ciphertext bytes are written after the FIPS core and any optional PQC adjuncts complete.

k3y_uri cond Blob path for the K3Y capsule. Encrypt writes the .k3y capsule here; later decrypt and unwrap calls read it back from the same URI.

id optional Stable payload identifier recorded in Trust metadata and returned to callers for audit correlation.

codes / enforce / info optional Policy codes, enforcement payload, and audit metadata committed into the seal as AAD. The exact same values must be supplied again when decrypting or unwrapping.

FIPS Core Stack AES-256-GCM session seal · ECDSA-P384 signatures · HKDF-SHA-384 derivation

aes_256_gcm_uri required FIPS · sealKey Vault URI for the AES-256-GCM key that seals the K3Y Trust capsule.

ecdsa_p384_uri optional FIPS · sigSigning key URI. kv:// = PEM secret; kvk:// = Key Vault HSM-side signing.

ecdsa_p384_secondary_uri optional FIPS · sig ×2Secondary ECDSA-P384 signing key for dual-signature coverage on the Trust capsule during encrypt.

Optional PQC Adjuncts NIST FIPS 203 / 204 / 205 algorithms layered on the FIPS core

kyber_768_uri optional PQC · FIPS 203Recipient ML-KEM-768 public key URI. If supplied, ΞNIGMA 3.0 wraps the K3Y capsule for post-quantum confidentiality before writing it to k3y_uri.

ml_dsa_uri optional PQC · FIPS 204ML-DSA signing key URI used to append the S1 Trust signature block during encrypt.

slh_dsa optional PQC · FIPS 205SLH-DSA signing key URI used to append the S2 Trust signature block during encrypt.

Response · 200 OK (Trust JSON)

{
  "trust_id": "trust-abc123",
  "payload_id": "audit-q2",
  "ciphertext_uri": "az://data/enc/audit",
  "k3y_uri": "az://trust/audit.k3y",
  "fips": true,
  "pqc": { "ml_kem": true }
}

Example

curl "$BASE_URL/v1/encrypt" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "source_uri": "az://data/in/audit",
    "destination_uri": "az://data/enc/audit",
    "k3y_uri": "az://trust/audit.k3y",
    "aes_256_gcm_uri": "kv://keys/enigma",
    "kyber_768_uri": "kv://keys/ml-kem-pub"
  }'

POST /v1/decrypt Sync · 200 OK

Synchronous direct decrypt. Reads the K3Y capsule, unseals it with the AES session key, verifies all policy commitments and signer expectations, then reads ciphertext bytes and writes restored plaintext bytes to destination_uri. The core stack is FIPS; optional PQC adjuncts are verified only when they were present during encrypt. Returns Trust JSON on success. If any commitment, GMAC chunk tag, or signature check fails, the call returns an error and no plaintext bytes are written.

Request Body · grouped by stack order

Inputs And Commitments

source_uri required Blob URI of the ciphertext bytes — the destination_uri from the original encrypt call and the data plane input into the stack.

destination_uri required Blob URI where restored plaintext bytes are written after the FIPS core and any optional PQC verification checks pass.

k3y_uri required Blob URI of the K3Y capsule produced during encrypt. Contains the sealed Particle seed, FIPS seal, and ECDSA signature.

codes / enforce / info optional Must match exactly what was committed during encrypt. Wrong values cause AES-GCM authentication failure before any plaintext is produced.

FIPS Core Stack AES-256-GCM unseal · ECDSA-P384 signer verification

aes_256_gcm_uri required FIPS · sealKey Vault URI for the AES-256-GCM key used to unseal the K3Y capsule.

expected_ecdsa_pk_sha256_hex optional FIPS · verifySHA-256 hex of the expected signer public key. Verified before plaintext is written. Compact alternative to the full hex form.

expected_ecdsa_pk_hex optional FIPS · verifyFull hex-encoded expected public key. Provide one or the other — not both.

Optional PQC Adjuncts NIST FIPS 203 / 204 / 205 algorithms layered on the FIPS core

kyber_768_uri optional PQC · FIPS 203ML-KEM-768 private key URI. Required if the incoming K3Y capsule was post-quantum wrapped during encrypt.

ml_dsa_uri optional PQC · FIPS 204ML-DSA verification key URI. Required if the capsule contains an S1 adjunct signature.

slh_dsa optional PQC · FIPS 205SLH-DSA verification key URI. Required if the capsule contains an S2 adjunct signature.

Example

curl "$BASE_URL/v1/decrypt" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "source_uri": "az://data/enc/audit",
    "destination_uri": "az://data/out/audit",
    "k3y_uri": "az://trust/audit.k3y",
    "aes_256_gcm_uri": "kv://keys/enigma",
    "kyber_768_uri": "kv://keys/ml-kem-sk"
  }'

POST /v1/keygen Sync · 200 OK

Generates the full key set for a deployment into the named Key Vault and returns a stable URI for each key. Run once per environment before calling encrypt, decrypt, or unwrap. The FIPS core stack includes the AES-256-GCM session key plus the primary and secondary ECDSA-P384 keys; the optional PQC adjuncts are Kyber-768, ML-DSA, and SLH-DSA when built with pqc-adjunct.

Request Body · grouped by deployment role

Vault Target

vault required Key Vault name or base URL where all key material is written. e.g. "pqc-kv".

Naming Shared prefix and overrides

prefix optional Name prefix for all generated keys. Default: "il7". Use per-environment values like "finance-prod" to isolate key sets.

key_name optional Override name for the AES-256-GCM key. Default: "{prefix}-aes".

ecdsa_secondary_name optional Override name for the secondary ECDSA-P384 key. Default: "{prefix}-ecdsa-sk-secondary".

Response · 200 OK

Returned URIs are grouped by stack: FIPS core first, then optional PQC adjunct keys.

FIPS core keys: aes_256_gcm, ecdsa_p384, ecdsa_p384_secondary. Optional PQC keys: kyber_768_pub, kyber_768_sk, ml_dsa_pk, ml_dsa_sk, slh_dsa_pk, slh_dsa_sk.

{
  "status": "ok",
  "vault": "pqc-kv",
  "prefix": "finance-prod",
  "uris": {
    "aes": "kv://pqc-kv/finance-prod-aes",
    "ecdsa": "kvk://pqc-kv/finance-prod-es384",
    "ml_kem_pub": "kv://pqc-kv/finance-prod-ml-kem-pub",
    "ml_kem_sk": "kv://pqc-kv/finance-prod-ml-kem-sk"
  },
  "additional": ["ML-DSA", "SLH-DSA"]
}

Example

curl "$BASE_URL/v1/keygen" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "vault":"pqc-kv", "prefix":"finance-prod" }'

POST /v1/unwrap Sync · 200 OK

Unseals a K3Y capsule and returns the authorized Trust metadata without touching the ciphertext payload. Use for audit inspection, provenance review, SIEM ingestion, and compliance reporting without needing write access to the plaintext destination. The FIPS core validates the capsule; optional PQC verification keys are only needed when the original encrypt used those adjuncts.

Request Body · grouped by unwrap flow

Capsule Input

k3y_uri required Blob URI of the K3Y capsule to unseal.

aes_256_gcm_uri required Key Vault URI for the AES-256-GCM key that unseals the capsule.

Commitments Must match the original encrypt call

codes / enforce / info optional Must match what was committed during encrypt. Wrong values cause authentication failure.

Optional PQC Verification Keys Only needed when adjuncts were used

kyber_768_uri optional PQC · FIPS 203Kyber-768 private key URI — required if the K3Y was KEM-wrapped with Kyber during encrypt.

ml_dsa_uri optional PQC · FIPS 204ML-DSA verification key URI — required if the capsule includes the S1 adjunct signature.

slh_dsa optional PQC · FIPS 205SLH-DSA verification key URI — required if the capsule includes the S2 adjunct signature.

Output Mode

return optional "trust_json" returns the full parsed Trust record as structured JSON. Omit for the raw capsule output.

Example

curl "$BASE_URL/v1/unwrap" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "k3y_uri": "az://trust/audit.k3y",
    "aes_256_gcm_uri": "kv://keys/enigma",
    "codes": ["7842","11903"],
    "enforce": "tenant:contoso policy:v3"
  }'

Diagnostics

GET /v1/health

Returns the service version, FIPS posture, entitlement state, cryptographic provider summary, and configured request limits. Use as a liveness and readiness probe.

Response · 200 OK

{
  "status": "ok",
  "version": "3.0.0",
  "fips": true,
  "entitlement": { "ok": true, "provider": "azure" },
  "limits": { "xor_chunk_mb": 16, "max_inflight": 8 },
  "crypto": {
    "symmetric": "AES-256-GCM/GMAC",
    "signing": "ECDSA-P384",
    "pqc": "enabled"
  }
}

POST /v1/test

Builds a synthetic in-memory payload, runs a full encrypt→decrypt roundtrip, and returns detailed timing and throughput metrics. No external storage is touched. Use to validate the deployment path and benchmark in-boundary performance immediately after provisioning.

Request Body · all fields optional — empty body accepted

health_mb optional Size of the synthetic payload in MB. Defaults to a minimal fitness value. Larger values stress-test in-boundary throughput and memory pressure.

Response · 200 OK

{
  "requested_bytes": 1048576,
  "tput_gib_s": 3.421,
  "enc_wall_s": 0.141,
  "dec_wall_s": 0.148,
  "roundtrip_s": 0.289
}

Example

curl "$BASE_URL/v1/test" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{ "health_mb":64 }'

POST /v1/kat

Runs the Known-Answer-Test suite against the live cryptographic implementation and returns test vectors alongside pass/fail state. Returns 200 on full pass; 500 if any vector fails. Use as a compliance self-check or during certification workflows.

Request Body · all fields optional — empty body accepted

emit optional If true, return only the test vectors without running the checks. Useful for offline vector export and external tooling integration.

compact optional If true, omit full hex vectors from the output and return only the result summary.

Covered Algorithms

HKDF-SHA-384 — Particle seed expansion
HMAC-SHA-256
AES-256-GCM — K3Y seal / unseal
GMAC-256 — per-chunk integrity tags
ECDSA-P384/SHA-384
AAD_v1 & Trust ID_v1 construction
Kyber-768, ML-DSA, SLH-DSA (pqc-adjunct)

Example

curl "$BASE_URL/v1/kat" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{ "compact":true }'

ΞNIGMA 3.0 Binary Interface

Restricted local streaming commands for encrypt, decrypt, Trust inspection, and key generation. Data moves through stdin and stdout; cloud staging is not required.

Local / air-gapped
stdin → process → stdout

Restricted access

Use requires Know Your Customer review and an approved Use Case agreement. Keys are supplied as hex-encoded command flags rather than cloud URIs.

encrypt

stdin plaintext → stdout ciphertext or a self-contained K3Y bundle.

decrypt

stdin bundle or raw ciphertext → verified plaintext on stdout.

trust

stdin K3Y → redacted Trust JSON. Payload bytes are not processed.

keygen

Creates AES, P-384, ML-KEM, ML-DSA, and SLH-DSA test material.

Bundle format [4-byte big-endian K3Y length] [K3Y capsule] [ciphertext]

encryptstdin plaintext → stdout ciphertext

--aes-hex <hex>required

--ecdsa-sk-hex <hex>required

--ecdsa-secondary-sk-hexoptional

--kyber-pub-hex <hex>optional

--ml-dsa-sk-hex / --ml-dsa-pk-hexoptional

--slh-dsa-sk-hex / --slh-dsa-pk-hexoptional

--id <string>optional

--code <value>repeatable

--info-hex / --enforce-hexoptional

--bundleswitch

decryptstdin ciphertext → stdout plaintext

--aes-hex <hex>required

--k3y-hex <hex>raw only

--expect-ecdsa-pk-hexpin

--expect-ecdsa-pk-sha256-hexpin

--kyber-sk-hex <hex>optional

--ml-dsa-pk-hex <hex>optional

--slh-dsa-pk-hex <hex>optional

--code <value>repeatable

--info-hex / --enforce-hexoptional

Bundle input embeds K3Y, so --k3y-hex is omitted. Supply one expected signer pin for verification.

trustK3Y → Trust JSON

--aes-hex <hex>required

--kyber-sk-hex <hex>optional

--ml-dsa-pk-hex / --slh-dsa-pk-hexoptional

--code / --info-hex / --enforce-hexoptional

keygenwrites data/keys/

all | fips | pqcselector

IL7_ALLOW_GENKEYS=1required

AWS_LC_RUST_FIPS=1required

build feature: bothtest stack

Writes AES, ECDSA P-384, Kyber-768, ML-DSA, and SLH-DSA files using the configured prefix.

Concise shell roundtripencrypt → decrypt → trust

export AWS_LC_RUST_FIPS=1
IL7_ALLOW_GENKEYS=1 il7 keygen all

cat audit.dat | il7 encrypt \
  --aes-hex "$AES" --ecdsa-sk-hex "$ECDSA_SK" \
  --kyber-pub-hex "$ML_KEM_PK" --bundle > audit.enigma

cat audit.enigma | il7 decrypt \
  --aes-hex "$AES" --expect-ecdsa-pk-hex "$ECDSA_PK" \
  --kyber-sk-hex "$ML_KEM_SK" > audit.restored

cmp audit.dat audit.restored
cat audit.k3y | il7 trust --aes-hex "$AES" --kyber-sk-hex "$ML_KEM_SK"

ΞNIGMA 3.0 // SECTION 11 // THREAT

Threat Model Summary

Harvest-now-decrypt-laterKyber-768 protects K3Y confidentiality against future quantum decryption, while the XOR layer leaves intercepted ciphertext unusable without the sealed seed.

Quantum signature forgeryML-DSA and SLH-DSA add PQ authentication; breaking ECDSA-P384 alone does not break the independent PQ signature layers.

Ciphertext tamperingPer-chunk GMAC tags over ciphertext, committed inside AES-GCM-authenticated Trust, detect bit flips, truncation, and unauthorized modification before plaintext is returned.

Unauthorized key accessWrong codes or enforce payloads cause AES-GCM authentication failure because the commitments are bound as AAD.

Replay attacksEach operation has a unique Trust ID and nanosecond timestamp. Optional anti-replay policy can enforce Trust ID uniqueness and freshness windows.

ΞNIGMA 3.0 // SECTION 12 // ONBOARDING

10-Step Onboarding to Production

From subscription to secure production jobs.

Create Subscription

Provision or designate the Azure subscription that will contain ΞNIGMA 3.0.

Deploy ΞNIGMA 3.0

Deploy into VM, AKS, or Container Apps inside your boundary.

Assign Managed Identity

Grant ΞNIGMA 3.0 least-privilege access to Blob Storage and Key Vault.

Load Keys

Import AES, ECDSA, Kyber, ML-DSA, and SLH-DSA material as your deployment permits.

Upload Test Data

Place sample objects in the backlog container or source path.

Health Check

Call /v1/health to verify FIPS, version, entitlement, and limits.

Submit First Job

Run the first encrypt/decrypt job through /v1/job.

Verify Output

Check ciphertext, K3Y envelope, unwrap Trust metadata, and GMAC verification.

Configure Logging

Forward logs to SIEM and enable QSCC / audit metering as needed.

Go Live

Enable production policies, quotas, entitlement gates, and operational monitoring.

ΞNIGMA 3.0 // SECTION 13 // COMMERCIAL

Commercial License · Usage Metering · Marketplace Entitlement

Simple usage pricing for encryption at enterprise scale.

ΞNIGMA 3.0 is licensed, not sold. The commercial model uses one clean meter: encrypted entropy volume. Customers pay for encryption; unlimited decryption of customer-owned data, Trust metadata, and cryptographic provenance objects are included in normal operation.

Base list price

$0.007

USD / MB encrypted

Public volume floor

$0.001

USD / MB at 1–10 EB/year · $1 / GB

Indicative Volume-Based Pricing Bands

Pricing steps down with sustained cumulative encrypted volume.

Metered by MB

Annual encrypted volume	Price / MB	Commercial note
0 – 10 PB/year	$0.007 ($7/GB)	Base commercial list price
10 – 50 PB/year	$0.006 ($6/GB)	Automatic volume reduction
50 – 100 PB/year	$0.005 ($5/GB)	Large departmental workloads
100 – 150 PB/year	$0.004 ($4/GB)	Enterprise-scale archives
150 – 300 PB/year	$0.003 ($3/GB)	Mission data pipelines
300 – 500 PB/year	$0.002 ($2/GB)	Multi-program adoption
500 – 750 PB/year	$0.0015 ($1.50/GB)	Strategic cloud-scale use
750 PB – 1 EB/year	$0.00125 ($1.25/GB)	Exabyte transition band
1 – 10 EB/year	$0.001 ($1/GB)	Lowest public band; below this requires private agreement

0 - 10 PB/year $0.007 / MB

Base commercial list price · $7 / GB.

10 - 50 PB/year $0.006 / MB

Automatic volume reduction · $6 / GB.

50 - 100 PB/year $0.005 / MB

Large departmental workloads · $5 / GB.

100 - 150 PB/year $0.004 / MB

Enterprise-scale archives · $4 / GB.

150 - 300 PB/year $0.003 / MB

Mission data pipelines · $3 / GB.

300 - 500 PB/year $0.002 / MB

Multi-program adoption · $2 / GB.

500 - 750 PB/year $0.0015 / MB

Strategic cloud-scale use · $1.50 / GB.

750 PB - 1 EB/year $0.00125 / MB

Exabyte transition band · $1.25 / GB.

1 - 10 EB/year $0.001 / MB

Lowest public band · $1 / GB; anything below requires private agreement.

License Rights

Commercial and non-commercial use

Subject to license compliance, ΞNIGMA 3.0 can be used for commercial and non-commercial encryption workloads. Usage is metered exclusively on encrypted entropy volume.

Unlimited customer-owned decrypt included
Trust metadata and provenance included
Permitted for bulk files, objects, logs, telemetry, backups, archives, and data pipelines

Sovereign Pricing

Treaty-scale floor by written agreement

A reserved floor of $0.001 USD / MB ($1 / GB) is the lowest publicly available band, applying at 1–10 EB/year. A sovereign floor below this rate is available only for treaty-scale, sovereign, or national infrastructure commitments of 10 EB/year or greater.

Pricing below $0.001 / MB is not public and requires an explicit private agreement.

Entitlement

Marketplace-gated cryptography

ΞNIGMA 3.0 checks marketplace entitlement at service startup through the cloud provider’s native entitlement API. Protected cryptographic operations remain disabled until an active entitlement is present.

entitlement.ok == true → encrypt/decrypt enabled
entitlement.ok == false → protected operations disabled

Optional QSCC Separate commercial agreement required

QSCC logging can turn verified encryption usage into climate-accountable telemetry.

Under separate agreement, customers may participate in Quantum-Secure Climate Credit programs. Records must match authoritative marketplace or licensing metering, and ΞNIGMA 3.0 may allocate up to 10% of calculated QSCC value back to the customer where authorized.

Accurate activity logs
Verified metered usage
Certificate reconciliation

Scope Guardrails Requires separate written authorization

ΞNIGMA 3.0 is purpose-built for encryption — not financial, identity, messaging, or consumer privacy platforms.

The separately governed ENIGMA issuance described below is not a general-purpose payment rail, customer wallet product, or permissionless blockchain service. Customer use of the core software remains restricted for payments, banking, third-party custody, crypto wallets, blockchain systems, identity providers, secure messaging, VPNs, password managers, randomness-as-a-service, key custody, surveillance, or competing resale unless explicitly authorized in writing.

No payments No wallets No SSO No messaging No VPN No resale

Full License Text

Commercial terms in-page for procurement review.

The complete uploaded ΞNIGMA 3.0 Commercial License is included below so procurement, security, and legal teams can review usage rights, restrictions, permitted uses, prohibited uses, QSCC participation, payment reporting, and liability terms.

Licensing: contact@hoteljuliett.com

Security support: security@hoteljuliett.com

Read ΞNIGMA 3.0 Commercial License

ΞNIGMA 3.0 COMMERCIAL LICENSE

Copyright (c) 2025 ΞNIGMA 3.0
All rights reserved.

This software and associated cryptographic systems (“ΞNIGMA 3.0”) are proprietary
and licensed for commercial use under the terms set forth below.

----------------------------------------------------------------------
COMMERCIAL LICENSE TERMS
----------------------------------------------------------------------

ΞNIGMA 3.0 is licensed, not sold. Use of this software constitutes acceptance of
these terms.

----------------------------------------------------------------------
PRICING AND METERING
----------------------------------------------------------------------

Base Pricing:
ΞNIGMA 3.0 encryption services are licensed on a usage-based model, metered by
encrypted entropy volume.

The base list price is:

    $0.007 USD per megabyte (MB) of encrypted entropy  ($7.00 / GB)

Pricing Adjustments:
ΞNIGMA 3.0 pricing decreases automatically with sustained encrypted volume.
Pricing reductions are applied solely based on cumulative usage and do not
require renegotiation or contract modification.

Indicative Volume-Based Pricing Bands:

- 0 - 10 PB/year:         $0.007 / MB   ($7.00 / GB)
- 10 - 50 PB/year:        $0.006 / MB   ($6.00 / GB)
- 50 - 100 PB/year:       $0.005 / MB   ($5.00 / GB)
- 100 - 150 PB/year:      $0.004 / MB   ($4.00 / GB)
- 150 - 300 PB/year:      $0.003 / MB   ($3.00 / GB)
- 300 - 500 PB/year:      $0.002 / MB   ($2.00 / GB)
- 500 - 750 PB/year:      $0.0015 / MB  ($1.50 / GB)
- 750 PB - 1 EB/year:     $0.00125 / MB ($1.25 / GB)
- 1 - 10 EB/year:         $0.001 / MB   ($1.00 / GB)

Pricing below $0.001 / MB is not publicly available and may only be offered
via explicit private agreement.

Sovereign-Grade Pricing:
$0.001 / MB ($1.00 / GB) is the lowest public band (1-10 EB/year).
A sovereign floor below this rate is reserved exclusively for treaty-scale,
sovereign, or national infrastructure agreements of 10 EB/year or greater,
and is subject to separate written agreement.

ΞNIGMA 3.0 enforces marketplace entitlement at service startup using the cloud provider’s native entitlement API. Cryptographic operations are disabled unless an active entitlement is present. Usage metering and entitlement enforcement are architecturally independent.

----------------------------------------------------------------------
USAGE RIGHTS
----------------------------------------------------------------------

Subject to compliance with this license:

- This software may be used for commercial and non-commercial purposes
- Usage is metered exclusively on encrypted entropy volume
- Unlimited decryption of customer-owned data is included at no additional cost
- Trust metadata and cryptographic provenance objects are included as part of
  normal operation

----------------------------------------------------------------------
QSCC LOGGING AND PARTICIPATION (OPTIONAL)
----------------------------------------------------------------------

ΞNIGMA 3.0 may support, under separate commercial agreement, participation in
Quantum-Secure Climate Credit (“QSCC”) programs intended to quantify and
certify environmental impact associated with encrypted data processing.

Customer Participation Requirements:
Participation in any QSCC-related program requires that the customer:

- Maintain accurate internal logs of ΞNIGMA 3.0 encryption and decryption activity,
  including encrypted volume, timestamps, and relevant job or workload
  identifiers
- Transmit required QSCC-related usage records to ΞNIGMA 3.0-designated systems for
  reconciliation, verification, and certificate generation
- Ensure that such records correspond to authoritative usage reported through
  applicable marketplace or licensing metering mechanisms

QSCC Attribution and Sharing:
Where QSCC participation is authorized in writing by ΞNIGMA 3.0:

- QSCC calculations are derived exclusively from verified, metered encryption
  usage
- ΞNIGMA 3.0 may, at its discretion and subject to separate agreement, allocate up to
  ten percent (10%) of the calculated QSCC value associated with a customer’s
  verified usage back to that customer
- QSCC allocation, valuation, certification, redemption, or transfer are not
  guaranteed and are subject to program terms, regulatory considerations, and
  future ΞNIGMA 3.0 product roadmap decisions

QSCC Scope Limitation:
QSCC participation does not constitute a financial product, security, payment
instrument, or transferable asset under this license. Any QSCC-related rights,
certificates, or value-sharing arrangements require a separate written
agreement and are expressly outside the scope of this license.


----------------------------------------------------------------------
EXPECTED AND PERMITTED USE
----------------------------------------------------------------------

ΞNIGMA 3.0 is designed and licensed exclusively as a high-performance encryption
engine for protecting data in motion and at rest within enterprise,
government, and infrastructure data pipelines.

Permitted use cases include, but are not limited to:

- Encryption of bulk data, files, objects, logs, telemetry, analytics outputs,
  backups, archives, and machine-generated datasets
- Protection of data flowing through cloud-native data pipelines, batch jobs,
  analytics systems, and storage services
- Long-term data protection where unlimited future decryption by the data
  owner is required
- Generation of cryptographic trust metadata and provenance information bound
  to encrypted outputs for audit and verification purposes

ΞNIGMA 3.0 is not licensed as a financial system, communications platform, identity
service, or end-user application. Uses outside the scope described above are
expressly prohibited unless authorized by a separate written agreement.

----------------------------------------------------------------------
PROHIBITED USES
----------------------------------------------------------------------

Unless explicitly authorized in writing by ΞNIGMA 3.0, this software may NOT be used,
directly or indirectly, for any of the following purposes:

Financial, Payments, and Monetary Systems:
- Financial transfers or payment processing
- Clearing, settlement, remittance, or custody systems
- Banking, stored value, or funds management services
- Escrow systems or conditional transfer mechanisms

Cryptocurrency and Blockchain:
- Cryptocurrency encryption, wallets, or key management
- Blockchain, distributed ledger, or token-based systems
- Digital asset exchanges or trading platforms

Identity, Authentication, and Access Control:
- Authentication, authorization, or identity provider services
- Single sign-on (SSO) or credential verification systems
- Digital signature or certificate authority services

Messaging and Communications:
- Secure messaging, chat, email, voice, or video applications
- End-user or consumer communications platforms
- Peer-to-peer encrypted communications

Consumer Security and Privacy Products:
- VPN services or secure browsing tools
- Consumer encryption or privacy applications
- Password managers or credential storage systems

Cryptographic Material Services:
- Randomness-as-a-service or entropy distribution
- Key generation, escrow, recovery, or custody services

Surveillance and Interception:
- Monitoring, interception, or surveillance systems
- Lawful intercept or wiretap tooling

Any use of ΞNIGMA 3.0 in the above categories requires a separate, explicit, written
agreement with ΞNIGMA 3.0 and is not permitted under this license.

----------------------------------------------------------------------
RESTRICTIONS
----------------------------------------------------------------------

Unless explicitly authorized in writing by ΞNIGMA 3.0:

- Redistribution, sublicensing, or resale is prohibited
- Modification, circumvention, or removal of licensing or metering mechanisms
  is prohibited
- Reverse engineering, decompilation, or disassembly is prohibited
- This software may not be offered as a competing service or embedded in a
  third-party product for resale

----------------------------------------------------------------------
PAYMENT AND REPORTING
----------------------------------------------------------------------

- License fees are calculated based on actual encrypted entropy processed
- Usage reporting and metering mechanisms must remain intact and operational
- Billing terms, invoicing cadence, rebates, credits, or QSCC-related programs,
  including any customer participation, reporting obligations, or value
  sharing, are governed exclusively by separate written commercial agreements
  and future ΞNIGMA 3.0 product roadmap offerings where applicable

----------------------------------------------------------------------
DISCLAIMER AND LIMITATION OF LIABILITY
----------------------------------------------------------------------

THIS SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT.

IN NO EVENT SHALL ΞNIGMA 3.0, ITS AUTHORS, OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT,
OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE
USE OR OTHER DEALINGS IN THE SOFTWARE.

----------------------------------------------------------------------
CONTACT
----------------------------------------------------------------------

Licensing inquiries:   contact@hoteljuliett.com
Security support:      security@hoteljuliett.com

ΞNIGMA 3.0 // NOT ANOTHER COIN // SECURITY PLANE FIRST

Category break · platform-governed · no mining · proposed issuance

ENIGMA // THE CATEGORY BREAK

ENIGMA.
Not another coin.

A coin exists to move value.
ENIGMA exists to protect it.

ENIGMA is proposed as the access, entitlement, and participation layer for a complete enterprise cryptographic system. It does not begin with a token contract and search for utility afterward. It begins with the security plane: data protection, K3Y Trust, policy gates, post-quantum controls, provenance, telemetry, cloud execution, and measurable operations.

No mining No meme economics No public-chain dependency No utility someday

01 // MOST TOKENS START HERE

Issue the asset.

Token contract→Community→Exchange→Promise utility

The economic object arrives first. Product utility, security depth, operating evidence, and enterprise adoption are expected to follow.

02 // ENIGMA STARTS HERE

Build the security plane.

Encrypt+Trust+Gate+Prove

The deployable system comes first. The proposed issuance layer is subordinate to real cryptographic work, controlled access, measured performance, and accountable operations.

The ENIGMA difference

Utility is not the roadmap. It is the starting condition.

The asset is not the product. The security platform is. ENIGMA’s proposed issuance architecture sits above an existing platform boundary and is designed to meter, entitle, and participate in useful security work—not replace that work with financial narrative.

Issuance price$90,000

Proposed fixed primary issuance price per whole ENIGMA token.

Minimum partial$1

One-dollar participation equals 1/90,000 of one token, or approximately 0.000011111 ENIGMA.

Maximum supply1B

Hard maximum of 1,000,000,000 whole tokens under the proposed issuance schedule.

One-dollar units90T

Up to 90 trillion one-dollar partial units across the theoretical maximum issuance.

Maximum issuance notional: $90 trillion. This is the mathematical product of the proposed $90,000 primary price and the one-billion-token ceiling. It is not current market capitalization, not capital raised, not a valuation guarantee, and not a forecast of secondary-market value.

Why ENIGMA is fundamentally different.

Bitcoin solved decentralized digital scarcity. Most later crypto assets organize a public ledger, smart-contract ecosystem, payment network, or speculative community. ENIGMA is positioned around a different center of gravity: cryptographic protection of mission and enterprise data.

No proof-of-work issuanceNo global mining contest, no block subsidy, no ASIC race, and no dedicated consensus power draw required to create or distribute ENIGMA.

Real platform boundaryThe proposed instrument is linked to a functioning encryption, Trust, key-management, API, entitlement, and audit architecture rather than a token contract alone.

Enterprise confidentialityBitcoin provides public-ledger integrity. ENIGMA is designed for confidential data handling, per-operation K3Y separation, gated decrypt, provenance, and regulated cloud deployment.

Dollar-level accessibilityA $90,000 whole-token price does not force a $90,000 minimum. Partials make the issuance addressable from $1 while preserving a fixed whole-unit reference price.

Environmental advantage by architecture.

ENIGMA does not add a second always-on economic network whose security depends on continuous competitive hashing. Its energy use is workload-bound: compute is consumed when customers encrypt, decrypt, attest, move, or verify data.

0×

Dedicated mining fleetNo ENIGMA-specific mining farms or specialized proof-of-work hardware are required for issuance.

0×

Consensus hash raceSecurity resources are directed toward customer cryptographic work instead of repeated global competition for the next block.

1×

Useful compute pathCPU cycles perform encryption, integrity, key wrapping, signatures, transport, and audit—not artificial work whose primary purpose is leader election.

Measurable operating impactQSCC telemetry can record bytes, wall time, throughput, and execution provenance so environmental claims can be measured rather than implied.

Dimension	Bitcoin	Typical crypto token	ENIGMA
Primary design goal	Permissionless settlement, scarcity, and censorship-resistant public consensus.	Varies: smart contracts, governance, applications, payments, community, or speculation.	Enterprise cryptographic access, entitlement, security utility, and participation.
Issuance mechanism	Mining and protocol-defined block rewards, declining toward a 21-million maximum.	Mining, staking, minting, airdrop, treasury, or contract-defined issuance.	Controlled primary issuance; $90,000 whole unit; $1 partial; 1B maximum.
Energy model	Continuous proof-of-work network with dedicated mining hardware and substantial electricity demand.	Depends on chain; proof-of-stake is generally lighter than proof-of-work but still maintains a separate consensus network.	No mining network. Energy follows useful security workload and cloud execution.
Security focus	Public ledger integrity and double-spend resistance; user funds depend on wallet and custody security.	Chain, bridge, wallet, validator, governance, and smart-contract risk vary by ecosystem.	Confidentiality, key separation, FIPS primitives, K3Y Trust, PQC adjuncts, gating, and provenance.
Best-fit advantage	Decentralization, neutrality, global liquidity, and permissionless transfer.	Programmability, network effects, community coordination, or application utility.	Regulated data protection, sovereign deployment, measurable throughput, and full-stack accountability.

PROPOSED ISSUANCE FRAMEWORK. This section describes a product and tokenomics concept, not an offer to sell, solicitation, promise of appreciation, deposit product, or investment recommendation. Final token rights, utility, registry, custody, transferability, liquidity, redemption, KYC/AML controls, tax treatment, accounting treatment, sanctions controls, and securities/commodities analysis require jurisdiction-specific legal documentation before issuance.

QSCC // QUANTIFIED SECURITY CLIMATE CREDIT // MEASURED DIFFERENCE

Measured by useful work · compared on equal workloads · credited only from the verified difference

The climate value is the difference we can prove.

QSCC turns operating telemetry into a climate-performance record. Every completed cryptographic job establishes the work performed—bytes protected, elapsed time, throughput, execution path, and provenance. The same workload is then compared with an approved alternative stack. The measured energy and emissions avoided by ΞNIGMA become the basis of the proposed QSCC Climate Credit.

01Measure the work

QSCC records the operational denominator: bytes, wall time, throughput, chunk and range timing, queue behavior, commit duration, hardware identity, region, and execution provenance.

02Compare like for like

The baseline must protect the same data volume at the same security and durability boundary. No credit is created by comparing unlike services or an isolated component with a complete platform.

03Credit the difference

Only positive, independently supportable avoided emissions become QSCC units. Negative or inconclusive comparisons produce no credit—not a marketing adjustment.

From Trust telemetry to climate ledger.

The existing QSCC path already observes when the work starts, when it ends, how many bytes move, and how quickly the platform completes the operation. Climate accounting adds measured energy, data-center overhead, grid carbon intensity, a declared comparator, and a signed methodology version.

Avoided CO₂e = (baseline kWh − ΞNIGMA kWh) × grid emissions factor

Work identityTrust ID, QSCC ID, workload bytes, cryptographic profile, destination, timestamp, and immutable methodology version.

Energy evidenceMetered device or host energy where available; otherwise an approved hardware-power model with utilization and duration.

Baseline evidenceEquivalent competitor architecture, hardware, security controls, data movement, redundancy, and operational boundary.

Credit lifecycleIssue, serialize, transfer where permitted, retire once used, and prevent duplicate environmental claims.

Illustrative QSCC comparison.

Enter measured or independently supportable assumptions. This calculator demonstrates the methodology; its defaults are placeholders and do not represent a certified claim.

Protected data volume · TB

Grid factor · kg CO₂e/kWh

Equivalent baseline · kWh/GB

Measured ΞNIGMA · kWh/GB

Avoided energy600 kWh

Avoided emissions0.240 tCO₂e

Potential QSCC units0.240

Illustrative only. A positive result is not a carbon credit until the baseline, measurement boundary, quantification, additionality where applicable, third-party verification, registry controls, and retirement rules are approved.

Underlying climate valueVerified avoided CO₂e

The QSCC token is not valued by waste. It is valued by avoided waste.

The economic and environmental reference is the quantified improvement over the closest equivalent system: less electricity, less cooling, less duplicated infrastructure, and no separate proof-of-work mining economy. A QSCC record can be attached to the K3Y Trust evidence for the workload that produced it, creating a traceable connection between protected data and the measured climate advantage.

CLIMATE-CREDIT STATUS. Until an approved carbon-crediting methodology, independent validation and verification, registry, anti-double-counting controls, and retirement process are in place, QSCC units should be described as internal or contractual climate-performance credits—not regulated carbon offsets and not instruments that reduce a purchaser’s Scope 1, Scope 2, or Scope 3 inventory. Any financial, tax, accounting, securities, commodities, environmental-claims, or transfer treatment requires separate legal and professional review.

METHODOLOGY REFERENCE POINTS. Comparative avoided-emissions reporting should follow a transparent equivalent-product baseline and disclose both positive and negative impacts: GHG Protocol avoided-emissions framework. Environmental marketing claims should be specific and substantiated: FTC Green Guides. High-integrity carbon credits require robust quantification, tracking, no double counting, and independent validation and verification: ICVCM Core Carbon Principles.

ΞNIGMA 3.0 // SPECIAL SECTION // COMPETITION + TOTAL COST OF OWNERSHIP

Closest public alternatives · assembled-stack economics · measurable impact

No single box.
No direct twin.

Based on reviewed public product materials, there is no verified direct equivalent that combines the same data-plane encryption engine, per-operation K3Y Trust object, FIPS-backed classical stack, post-quantum adjuncts, cloud object I/O, gated decrypt, provenance, API orchestration, usage entitlement, and proposed issuance layer in one bounded platform. The closest alternatives are assembled from multiple products.

Verified direct public equivalents found

That does not mean no organization can recreate the outcome. It means the competing route is usually a program: select a KMS or HSM, add data encryption, add a PQC migration layer, build orchestration, integrate object storage, create audit evidence, operate the stack, and reconcile multiple commercial meters.

Closest enterprise platform

Thales CipherTrust

Strong centralized key management, transparent encryption, tokenization, cloud key control, and hybrid deployment.

Still requires separate workload-specific data-plane design, ENIGMA-style K3Y provenance, PQC adjunct integration, orchestration, and issuance architecture.

Closest unified security platform

Fortanix DSM

Combines HSM, KMS, secrets, tokenization, signing, and confidential-computing capabilities in a unified platform.

Excellent key and data-security control plane, but not the same position-addressable Particle XOR engine, K3Y lifecycle, Trust schema, and metered encryption service.

Closest PQC control plane

QuSecure QuProtect

Focused on cryptographic discovery, remediation, reporting, crypto-agility, and post-quantum network protection.

PQC modernization layer rather than a complete bulk-data encryption, key capsule, cloud object, entitlement, and provenance stack.

Lowest component price

Cloud KMS / HSM

AWS KMS, Azure Key Vault, Google Cloud KMS, and managed HSM services provide inexpensive key operations and protected key storage.

They are essential primitives, not a full ENIGMA competitor. Customers must still build the encryption data plane, K3Y equivalent, PQC layer, policy gates, telemetry, and operating model.

Assembled competitor stack7layers to buy, join and operate

ENIGMA1bounded platform

The ENIGMA difference

Buy the completed security plane—not the assembly project.

ENIGMA combines the data engine, K3Y Trust capsule, classical and post-quantum controls, cloud-object execution, policy gates, provenance, telemetry, entitlement, and API operations behind one platform boundary. Competing programs can reproduce pieces; they must still integrate, secure, evidence, upgrade, and operate the seams between them.

One platform boundaryOne API surfaceOne evidence modelOne commercial meter

The real comparison is full-stack TCO.

Comparing ENIGMA only with a low-cost KMS transaction line item is category error. A cloud KMS protects and uses keys. A complete mission-data program also pays for encryption software, HSM or KMS services, integration, cloud transport, security engineering, PQC migration, audit evidence, deployment automation, on-call operations, vendor management, and compliance maintenance.

01KMS / HSM / key custodyComponent

02Bulk-data encryption engineComponent

03PQC and crypto-agility layerComponent

04Object I/O and orchestrationIntegration

05Trust, provenance, gates, auditEngineering

06Compliance, operations, upgradesOngoing

07Metering and entitlementCommercial

Transparent full-stack TCO.

Change every assumption. The model compares ENIGMA’s published volume rate with the recurring cost of assembling and operating the closest functional stack—not with one inexpensive KMS transaction line.

Annual encrypted volume · TB

Competitor platform licenses · $/yr

KMS / HSM / cloud security · $/yr

Integration + crypto engineering · FTE

Loaded annual cost per FTE · $

Audit, compliance, operations · $/yr

ENIGMA integrated platform$700,000

Assembled-stack annual TCO$1,960,000

Estimated annual reduction$1,260,000

Relative annual operating cost64% lower

ENIGMA integrated platform$700,000

Assembled competitor stack$1,960,000

At 100 TB/year, the current public ENIGMA band is $7/GB. This model is illustrative, excludes cloud storage and network egress common to both approaches, and is not a vendor quote.

Security improvementFewer seams to attack.

One bounded system reduces handoffs among key managers, encryption agents, PQC gateways, audit databases, workflow engines, and custom glue code. Fewer trust boundaries mean fewer configuration gaps and fewer places for policy drift.

Cost reductionReplace a program, not a primitive.

ENIGMA consolidates engineering, orchestration, Trust evidence, crypto integration, and entitlement around one metered service. Savings are greatest where organizations would otherwise assemble and operate multiple enterprise layers.

Environmental improvementUseful work only.

No proof-of-work mining, no ENIGMA-specific validator economy, and no artificial consensus load. Compute and energy are directed toward encrypting, verifying, transporting, and accounting for customer data.

PUBLIC REFERENCE POINTS. Bitcoin’s protocol-defined mining and 21-million cap: Bitcoin.org. Bitcoin proof-of-work electricity and GHG methodology: Cambridge CBECI. Component pricing examples: AWS KMS, Azure Key Vault, and Google Cloud KMS. Closest-platform product descriptions: Thales CipherTrust, Fortanix DSM, and QuSecure QuProtect. Comparative and TCO statements are architectural analysis and illustrative modeling, not third-party certifications or vendor quotations.

ΞNIGMA 3.0 // SECTION 14 // ENGINEERING DEEP DIVE

Bottom Technical Appendix FIPS Boundary Engineering Review

The implementation details behind the marketing claim.

This appendix keeps the launch page readable while preserving a meaningful technical review: FIPS DRBG seeding, domain-separated derivation, position-addressable state refresh, 128-byte block emission, parallel XOR, and the review findings that explain why the stream can run fast without exposing raw seed material, keystream bytes, or private keys.

Engineering Deep Dive — Stream Architecture Review

ΞNIGMA 3.0 uses a position-addressable keystream engine for bulk payload transformation. Given the same 384-bit seed and a block index, it always produces the same 128-byte block, This property is what enables safe, lock-free parallel encryption.

The engine is a custom construction, so this appendix describes the review posture rather than publishing a source-map of internal identifiers. Every security-sensitive step still delegates to FIPS primitives, and the keystream is only one layer in a larger authenticated design.

1 Phase 1 — FIPS DRBG Seeding

Engineering insight: seed generation, lifetime control, and one-time-use guarantees.

The seed is 384 bits of raw entropy drawn from the AWS-LC SP 800-90A CTR_DRBG — the same FIPS-validated source used for all key material in ΞNIGMA 3.0. The 384 bits are organized as six independent 64-bit words that are assembled into the engine seed structure.

Why six words? The engine state tracks seven derived variables plus four schedule sub-keys. Seeding with six independent 64-bit draws keeps the initial state decorrelated before any derivation step expands it further.

// FIPS DRBG supplies the entire 384-bit seed budget

DRBG output → six 64-bit seed words

Seed words → engine seed object

Seed object → sealed Trust capsule

// Review conclusion: one fresh seed per protected operation

Security & Memory Properties

One-time use only. The seed is created once per protected operation, committed into Trust, and sealed under AES-256-GCM. It is not meant for logs, disk output, or operator inspection.
Zeroize discipline. Seed-holding types and temporary byte buffers are cleared after use so the entropy does not persist longer than required.
No seed reuse. Even if two encrypt calls happen nanoseconds apart, each draws fresh entropy from the DRBG. There is no global counter, no time-derived component, and no seed caching.
Derived-byte cleanup. The seed's byte encoding is treated as transient working material and cleared immediately after schedule derivation.

2 Phase 2 — HKDF-SHA-384 Schedule Derivation

Engineering insight: deterministic derivation, domain separation, and bounded secret exposure.

The 48-byte seed is passed through HKDF-SHA-384 using a fixed domain separator to produce a pseudorandom key. Four 64-bit schedule sub-keys are then expanded with distinct labels so the refresh logic gets separate inputs for each role. These sub-keys are the only cryptographically derived values — all further computation is integer mixing that the CPU can pipeline efficiently.

// Fixed domain separator keeps derivation deterministic

PRK = HKDF-SHA-384(domain_separator, seed_bytes)

// Independent expansions for schedule roles

schedule_key_1 = HKDF-Expand(PRK, label A)

schedule_key_2 = HKDF-Expand(PRK, label B)

schedule_key_3 = HKDF-Expand(PRK, label C)

schedule_key_4 = HKDF-Expand(PRK, label D)

// Seed buffer immediately cleared

seed_bytes.zeroize()

Three schedule keys track the primary state lanes. Each remains bound to the original entropy while still being independently derived.

A fourth schedule key seeds the global mixing term that propagates across every output word before any bytes are emitted.

The fixed domain separator is intentional: it keeps derivation deterministic for auditability while still separating this use of HKDF from every other use in the system. Security comes from the seed entropy, not from hiding the label.

3 Phase 3 — Position-Addressable State Refresh

Engineering insight: diffusion, deterministic seeking, and worker-safe parallelism.

The SplitMix64 Finalizer

Every state word is produced by passing it through a 64-bit avalanche mixer based on the SplitMix64 finalizer family, a well-known bijective 64-bit hash function with near-perfect avalanche properties (every output bit depends on every input bit). It is not a random function: given the input you can compute the output, and vice versa. Its role is diffusion: ensuring that a 1-bit difference in any input spreads to roughly 32 output bits.

// Avalanche mixer: xor-shift and multiply rounds

mixed = diffuse(seed_lane ^ schedule_lane ^ step ^ global_term)

repeat with rotated inputs for each state lane

// The review cares about diffusion properties, not publishing literals

// Strict avalanche criterion satisfied for all 64 bits

Why Position-Addressable Matters

The refresh step is a pure function of seed, schedule, and block index. It does not accumulate state — the same block index always yields the same seven words, regardless of whether you arrived there sequentially or jumped directly.

// These are equivalent — no sequential dependency:

engine_at_step(seed, 1_000_000)

// vs stepping from 0 → 999_999 → 1_000_000

// Rayon workers exploit this:

chunk[0]: derive block 0 // worker A

chunk[1]: derive block 8192 // worker B

chunk[2]: derive block 16384 // worker C

// All three run simultaneously, zero coordination

State Word Computation Order

The order is deliberate: the global mixing term is computed first and injected into every subsequent word, creating a cross-word dependency at no extra cost.

1. Global influence first

The refresh step begins with a single mixed term derived from seed material, schedule material, and block position. That shared term is intentionally carried into every later state update.

2. Primary lanes stay distinct

Three primary lanes use different rotations and constants so the engine avoids collapsing into a single repeated pattern across adjacent words.

3. Companion lanes cross-feed

Later lanes depend on earlier outputs, which increases diffusion and makes the block state more coupled before bytes are emitted.

The implementation uses a fixed family of odd 64-bit multipliers and rotation offsets selected for dispersion and auditability. The public claim here is the review outcome: lane updates are deterministic, decorrelated, and reproducible under test.

4 Phase 4 — 128-Byte Block Emission

Engineering insight: block structure, whole-state influence, and temporary buffer hygiene.

Each step emits exactly 128 bytes (16 × 64-bit words) organized in two tiers. Before any word is written, a per-block tau_mix aggregate is derived from all seven state words plus the step counter — this ensures every output byte is a function of the entire engine state, preventing partial-state recovery from observing a single output word.

Tier 1 — Fast path

The first half of the block favors throughput. It combines the current state with a per-block aggregate term and inexpensive rotations so bulk encryption stays fast.

Public takeaway: fast path words still depend on the whole block state, not on isolated single lanes.

Tier 2 — Mixed path

The second half of the block reintroduces schedule material and another round of mixing. This raises diffusion depth without changing the fixed block size.

Public takeaway: later words are more heavily remixed before emission, and temporary buffers are zeroized after use.

Tier 1 provides throughput for bulk encryption (single XOR + rotate per word). Tier 2 provides depth: each word passes through mix64 again with a distinct HKDF sub-key and rotation offset, raising the algebraic complexity for any differential analysis. The temporary w[16] array is zeroized immediately after the output bytes are written.

5 Phase 5 — Parallel XOR Encryption

Engineering focus: aligned chunking, constant-time seekability, independent workers, and predictable throughput.

Chunk Sizing Strategy

The parallel path uses aligned work units that are large enough to keep each worker busy without creating unnecessary scheduling overhead.

Work is split on whole block boundaries so every worker starts at a valid stream position.

Small buffers stay single-threaded to avoid paying orchestration costs that outweigh the gain.

Large buffers scale across workers because each range can be derived independently from its starting offset.

Buffers < 256 KiB skip Rayon entirely — single-threaded path avoids task-spawn overhead for small blobs.
Chunk size is STEP_BYTES-aligned so every worker's starting byte offset maps exactly to a whole block index — no partial-block arithmetic at chunk boundaries.
Each worker constructs its own byte-offset view of the engine independently. No shared mutable state, no mutexes, no false sharing.

Non-Aligned Offset Handling

The byte-offset constructor handles the case where a chunk starts mid-block. It computes step = N / 128 and skip = N % 128, positions the engine at that block, then discards the first skip keystream bytes before beginning output. This is correct because the engine state is deterministic for any given step — seeking to block N is O(1).

// xor_fill handles initial skip transparently

if self.skip != 0 {

self.step_once(); self.emit_block(&mut blk);

// XOR only blk[skip..] for the first partial block

self.skip = 0; // all subsequent blocks are full

}

// Remaining blocks: full STEP_BYTES XOR each

while off < data.len() {

self.step_once();

self.emit_block(&mut blk);

xor blk[..n] into data[off..off+n];

blk.zeroize();

}

ENGINEERING STRENGTH // CRYPTOGRAPHY, MEMORY, DATA PLANE, OPERATIONS

Tight at Every Layer

The codebase is built as one coherent security system rather than a collection of isolated features. Secrets are short-lived, boundaries are explicit, cloud I/O is controlled, and every major operation is measurable. The result is disciplined engineering from the first parsed URI through the final committed ciphertext block.

08Layer strengths

FIPSCrypto boundary

E2EMeasured execution

Cryptographic control

Tight security foundations

Zeroized secrets by default

AES keys, K3Y material, private keys, and other sensitive buffers are wrapped in zeroizing containers or explicitly cleared after use. Secret cleanup is part of normal ownership and drop behavior—not an optional afterthought.

VAL

Strict boundaries before work begins

Typed cloud URIs, explicit scheme parsing, vault matching, fixed AES-256 length checks, and bounded K3Y validation reject malformed or misplaced material before cryptographic processing starts.

Clean FIPS and signing boundary

Standardized cryptographic services remain easy to identify: AWS-LC-backed primitives, SHA-384 prehashing, ES384 signing through Azure Key Vault, and explicit P1363-to-DER normalization keep the signing path precise and explainable.

ERR

Failure-closed orchestration

Unsupported modes, incorrect URI types, missing keys, invalid lengths, vault mismatches, and incomplete K3Y inputs return explicit errors. The system does not silently downgrade, guess, or continue across a broken security assumption.

Cloud and runtime precision

A controlled data plane

API

Provider contracts stay separated

InputSource, OutputSink, and KeyProvider traits isolate storage, output commitment, and key retrieval. The cryptographic job path depends on clear capabilities instead of cloud-specific implementation details.

↓∥

Concurrent reads remain ordered

Azure blobs are split into configurable byte ranges, downloaded concurrently, and reassembled in deterministic order. Each range is measured independently while the consumer still receives one continuous stream.

↑✓

Backpressured, commit-gated writes

Bounded channels, configurable block sizes, concurrent block uploads, queue and in-flight counters, and a final block-list commit create a controlled write path that does not declare success before storage is complete.

Telemetry proves the execution

QSCC instrumentation records bytes, wall time, throughput, chunk counts, range timing, block timing, queue depth, and commit duration. Performance and operational behavior are observable at the same boundaries where the work occurs.

✓

Engineering posture

From parsing to key handling to cloud transfer, each layer owns its state, validates its inputs, records its work, and closes cleanly. That is what tight engineering looks like: explicit contracts, bounded concurrency, zeroized secrets, deterministic behavior, and no hidden shortcuts between the customer boundary and the protected output.

Security Posture Summary

The Particle Engine is not a standardized cipher and makes no claim of independently providing computational security against a classical adversary with unlimited time. The Particle Engine is an OTP-inspired, seed-expanded XOR construction — not a formal Shannon OTP, since the keystream is derived from a 384-bit seed rather than drawn from message-length uniform randomness. Its practical security rests on seed confidentiality: the seed is drawn from a FIPS SP 800-90A DRBG, committed into a cryptographically authenticated capsule (AES-256-GCM), and never exposed in plaintext. Without the sealed K3Y — which itself requires the AES session key to open — an attacker holding only ciphertext has no algebraic foothold. The engine's mixing provides statistical quality (verified via dieharder) and diffusion; the AES-GCM–sealed Trust capsule provides the computational security binding that ties the stream to a specific authorized party.

ΞNIGMA 3.0 // SECTION 15 // OPERATIONS SURFACE

Operations Surface

This section mirrors the API reference exactly so operators can scan the same endpoint contract again at the bottom of the page without hunting for changed wording.

POST /v1/job

Recommended managed interface for encrypt or decrypt jobs that should return a status URI.

GET /v1/job/{id}

Fetch the current status, trust output, and terminal error details for a managed job.

POST /v1/encrypt

Direct encrypt path for byte streams already staged at the supplied source and destination URIs.

POST /v1/decrypt

Direct decrypt path that restores protected byte streams once K3Y, gates, and signer checks pass.

POST /v1/keygen

Generate the AES, ECDSA, and optional PQC key set and return stable vault URIs for later calls.

POST /v1/unwrap

Return authorized Trust metadata from a K3Y artifact without restoring payload bytes.

GET /v1/health

Verify version, FIPS posture, entitlement state, and configured request limits.

POST /v1/test

Build and run a health roundtrip payload to validate the deployment path end to end.

POST /v1/kat

Run known-answer-test reporting for deeper cryptographic self-checks and compliance workflows.

ΞNIGMA 3.0 // SECTION 16 // NIST FIPS REVIEW

NIST & FIPS Review

Bottom-line standards review for operators and assessors: where ΞNIGMA 3.0 is strongest today, what is implemented, and what is checked off in the current build posture.

Where We Are Strong

Clear FIPS core boundary: AES-256-GCM, GMAC, HKDF, ECDSA-P384, and DRBG are explicitly mapped to the AWS-LC backed FIPS posture.
Layered integrity: per-chunk GMAC plus Trust-capsule authentication and signer validation before plaintext release.
PQC without replacing FIPS core: ML-KEM, ML-DSA, and SLH-DSA are additive adjuncts rather than single points of dependency.
Operational auditability: key URIs, Trust metadata, unwrap flows, and KAT/health surfaces provide assessor-friendly evidence paths.

Certification Status Note

Checked items below indicate standards implemented and wired into runtime behavior in this release. They do not claim independent CMVP product validation or a formal authorization package by themselves.

Implemented: algorithm and control mapping in code and API behavior.

Ready for review: explicit stack boundaries, Trust artifacts, and diagnostics for assessor walkthroughs.

Program-level validation: remains subject to formal external process and scope decisions.

SBOM & Supply Chain

SPDX 2.3 (il7.spdx.json) and CycloneDX (il7.cyclonedx.xml) generated per release via make sbom.
checksums.txt covers binary + both SBOM artifacts; GPG-signed as checksums.txt.asc by the il7-release workflow.
cargo deny check --all-features --workspace --locked enforces advisories, license policy, and source rules in CI.
cargo audit --locked gates every release on a clean RustSec advisory scan.

CM-8 · SA-12 · RA-5

Container Readiness

Multi-stage Dockerfile: builder on rust:1.88.0-slim, distroless runtime image — no shell, no package manager, no write paths.
Non-root runtime: UID 10001; read-only filesystem; no host mounts in production.
Multi-arch buildx outputs for AMD64 and ARM64 (Azure Cobalt). AWS_LC_RUST_FIPS=1 injected at build time.
Deterministic: Rust toolchain pinned; deps locked; no runtime mutation; CI-enforced configuration baseline.

AC-6 · CM-2 · CM-2(1) · IL6/FedRAMP

Rust Implementation

Single cryptographic provider: aws-lc-rs = "=1.17.0" pinned exactly; CMVP #4816.
Pervasive zeroize on all seed-holding types and scratch buffers — enforced via derive trait, not best-effort.
No unsafe in the cryptographic hot path; lock-free parallelism via Rayon with position-addressable keystream — no shared mutable state.
PQC (oqs 0.9) feature-gated behind pqc-adjunct; TLS cert path uses rustls only — native-tls dropped across all crates.

SC-13 · SA-11b · IA-5

Test Suite

ecdsa_stack_tests — full primary + secondary ECDSA roundtrips verifying Trust JSON stack flags.
aad_collision_tests — length-prefix collision prevention, determinism, None/empty boundary, and info isolation.
kat_vectors — known-answer-test coverage for HKDF-SHA-384, HMAC-SHA-256, AES-256-GCM, GMAC, ECDSA, AAD_v1, and PQC adjuncts.
nonce_uniqueness_tests — statistical uniqueness, entropy, length, salt stability, parallel uniqueness, and distribution.
particle_key_security_tests — no-Debug, no-Clone trait enforcement, zeroization, borrow safety, and integration coverage.
fitness_suite — in-binary encrypt→decrypt roundtrip harness (PQC-gated); also surfaced at runtime via POST /v1/test.

SA-11 · SI-2 · AU-2

Standards Checklist

Standard	Status	What Is Checked Off	Notes
FIPS 140-3 posture (runtime boundary)	Checked	FIPS-gated crypto path, AWS-LC-backed primitives, health/API surfacing of posture.	Module/certificate scope is external to this page.
NIST SP 800-90A DRBG usage	Checked	Per-operation seed generation and randomness path documented in ITS/FIPS stack.	Used for seed and nonce generation inputs.
FIPS 186-5 ECDSA-P384 signatures	Checked	Primary (and optional secondary) Trust signatures with decrypt-time pin/verify options.	Classical signature baseline remains always-on.
NIST FIPS 203 ML-KEM (Kyber-768)	Checked (Optional)	K3Y wrap/unwrap adjunct via `pqc-adjunct` key URIs and runtime flow.	Adjunct to FIPS core, not replacement.
NIST FIPS 204 ML-DSA	Checked (Optional)	S1 Trust signature adjunct with verify on decrypt/unwrap when present.	Feature-gated; interoperates with ECDSA baseline.
NIST FIPS 205 SLH-DSA	Checked (Optional)	S2 stateless hash-based signature adjunct with verify on decrypt/unwrap when present.	Independent PQ signature family for diversity.

ΞNIGMA 3.0 // SECTION 17 // QUICKSTART

Quick Start

Onboard in under 10 minutes on Azure.

Four steps from a fresh deployment to live encrypt / decrypt with a sealed K3Y Trust capsule sitting in your Blob container.

Keygen

Generate your key set

Hit POST /v1/keygen with your Key Vault URI. ΞNIGMA 3.0 provisions an AES-256-GCM session key, an ECDSA P-384 signing pair, and optional Kyber-768 public key material — then writes stable vault URIs back to you.

POST /v1/keygen
{
  "vault_uri": "kv://pqc-kv",
  "alias": "onboard-demo"
}

~2 seconds

Point to Blob

Drop a file in Blob Storage

Upload any file to your Azure Blob container. Pass the source URI and a destination URI in the job manifest. ΞNIGMA 3.0 reads the bytes in-boundary — your data never leaves the customer subscription.

"source_uri":
  "az://pqc/plain/report.parquet",
"destination_uri":
  "az://pqc/enc/report.parquet"

Any file type · any size

Encrypt

Submit the encrypt job & watch it go

One POST /v1/job call starts the operation. ΞNIGMA 3.0 applies the Particle XOR stream, seals with AES-256-GCM, signs with ECDSA P-384, and writes the ciphertext blob plus a sealed K3Y Trust capsule in one atomic pass.

"type": "encrypt",
"k3y_uri":
  "az://pqc/k3ys/report.k3y",
"aes_256_gcm_uri":
  "kv://pqc-kv/onboard-demo"

FIPS + PQC full stack applied

Decrypt & Verify

Decrypt and inspect the K3Y capsule

Submit the same manifest with "type": "decrypt". ΞNIGMA 3.0 verifies the GMAC tag, checks the ECDSA signature, reconstructs the keystream, and writes plaintext back to Blob. The .k3y file stays sealed in your Blob container as an auditable Trust record.

az://pqc/plain/report.parquet✓ restored

az://pqc/k3ys/report.k3ysealed

GMAC + ECDSA P-384 verified

.k3y Trust capsule remains in your Blob

Ready to run the first job?

Deploy ΞNIGMA 3.0 into your Azure subscription, run POST /v1/keygen, drop a file, and submit the encrypt job. The K3Y Trust capsule will be waiting in your Blob container before your coffee cools.

API Reference Full Onboarding Guide

Final contact // HOTELJULIETT.COM

Signal acquired.
Juliett is on station.

Licensing, deployment planning, security review, platform integration, and mission onboarding start at one locked rendezvous point. Reach the domain, open the channel, and move directly into the customer boundary.

Mission onboarding Security review Platform integration

ENIGMA +3 → H Q L J P D → HOTELJULIETT.COM

Primary domain HOTELJULIETT.COM Open the locked channel →

General contact contact@hoteljuliett.com Security review security@hoteljuliett.com

System status Operational

Complete content build 3.0.0-2026.07

Verified C = M ⊕ K

PerfectSecrecyThroughout

Oh Juliett,where art though?

The machine that made secrecy move.

What it was

What it meant

What we inherit

Measured cryptographic throughput.

One job.Zero ambiguity.

You send pointers.

We lock the bytes.

Keygen forges the stack.

Azure deployment surface.Primary cloud path today.

Particle XOR Layer — Not AES-at-Rest

The byte layer is not AES-at-rest.One-time Particle XOR. Seed sealed in K3Y.

Quantum algorithms target mathematical structure. Particle XOR ciphertext minimizes that surface.

The key is where quantum risk lives. So we seal it with PQC.

Every encrypt operation gets abrand new K3Y. Zero exceptions.

Two ciphertexts, same key = plaintext exposed

The seed is born, used once, and sealed. It cannot escape.

FIPS Cryptographic Stack

Symmetric — AES-256-GCM

Streaming Integrity

Key Derivation

ECDSA-P384

Randomness

Policy Binding

Post-Quantum Cryptography Adjunct

Kyber-768 / ML-KEM-768

CRYSTALS-Dilithium

SPHINCS+ / SLH-DSA

Algorithm Summary

Kyber-768 / ML-KEM-768

ML-DSA / Dilithium

SLH-DSA / SPHINCS+

ECDSA-P384

K3Y Trust Capsule

codes

enforce

info

Trust Payload

Separation of K3Y and Ciphertext

Seal, Wrap, Sign

GMAC Chain

End-to-End Encryption Flow

API Reference

ΞNIGMA 3.0 Binary Interface

Threat Model Summary

10-Step Onboarding to Production

Create Subscription

Deploy ΞNIGMA 3.0

Assign Managed Identity

Load Keys

Upload Test Data

Health Check

Submit First Job

Verify Output

Configure Logging

Go Live

Simple usage pricing for encryption at enterprise scale.

Indicative Volume-Based Pricing Bands

Commercial and non-commercial use

Treaty-scale floor by written agreement

Marketplace-gated cryptography

QSCC logging can turn verified encryption usage into climate-accountable telemetry.

ΞNIGMA 3.0 is purpose-built for encryption — not financial, identity, messaging, or consumer privacy platforms.

Commercial terms in-page for procurement review.

ENIGMA.Not another coin.

Issue the asset.

Build the security plane.

Why ENIGMA is fundamentally different.

Environmental advantage by architecture.

The climate value is the difference we can prove.

From Trust telemetry to climate ledger.

Illustrative QSCC comparison.

The QSCC token is not valued by waste. It is valued by avoided waste.

No single box.No direct twin.

Thales CipherTrust

Fortanix DSM

QuSecure QuProtect

Cloud KMS / HSM

Perfect
SecrecyThroughout

Oh Juliett,
where art though?

Azure deployment surface.
Primary cloud path today.

The byte layer is not AES-at-rest.
One-time Particle XOR. Seed sealed in K3Y.

Every encrypt operation gets a
brand new K3Y. Zero exceptions.

ENIGMA.
Not another coin.

No single box.
No direct twin.

Signal acquired.
Juliett is on station.