One platform story. Seven layers of proof.
The slides state the claims. The next seven chapters prove each one operationally—from Particle Origin and FIPS/PQC through governed recovery, evidence, economics, and deployment inside the customer boundary.
PQC + FIPS + fresh per-operation random state.
ΞNIGMA is not selling one algorithm in isolation. It separates three jobs that are often collapsed together: fresh random origin generation, standardized classical protection around Trust and recovery, and post-quantum hardening for longer-lived recovery and authentication material.
The architecture is layered on purpose.
The per-operation Particle Origin begins with fresh randomness. The standardized classical layer supplies authenticated sealing, key derivation, integrity and signatures. PQC is additive: it can harden K3Y confidentiality and Trust authenticity without obscuring which controls actually protected the job.
One operating boundary instead of a stitched security program.
The value proposition is the integration: fresh-origin data protection + FIPS-backed controls + optional PQC + governed recovery + evidence are presented as one bounded service rather than separate operational projects.
Six randomized 64-bit coordinates form a new Particle Origin for each new encryption operation.
Standardized cryptographic primitives protect Trust, integrity, derivation and provenance.
Post-quantum KEM and signature paths can be enabled around recovery and authentication.
Operation state, policy, integrity, provenance and cryptographic posture are bound into the recoverable security record.
Chapter 02 isolates the entropy/origin path: how fresh random material becomes a compact Particle Origin, how the stream is addressed, and where the random-generation assurance boundary ends.
384 bits establish the origin. The stream is reconstructed only where the bytes are needed.
Each encryption operation begins with six fresh 64-bit coordinates—x, y, z, r, p, t—drawn independently through the FIPS-backed random-generation path. Together they form the operation-specific 384-bit Particle Origin. ΞNIGMA does not pre-generate or store a payload-sized pad. Instead, the engine deterministically recreates exactly the Particle bytes required for a given absolute position as encryption or authorized recovery proceeds, allowing large objects to be processed in parallel while retaining compact protected recovery state.
Fresh randomness is retained as compact recovery state—not as a second object-sized secret.
A classical OTP requires secret random material at least as long as the message. ΞNIGMA makes a different trade: fresh per-operation entropy establishes compact state, while a deterministic position-addressable trace recreates the payload-length XOR stream as needed. That enables direct seeking, parallel ranges and compact recovery.
Fresh random origin. Computational confidentiality.
The fresh entropy itself is genuine random input. The expanded Particle stream is deterministic from compact state, so ΞNIGMA does not present it as classical OTP perfect secrecy.
Per-operation origin and nonce material come from the FIPS-backed random-generation path.
Entropy-source assessment requires provider-specific evidence; this page does not establish independent SP 800-90B validation.
Workers can recreate specific ranges without depending on one shared mutable stream cursor.
The operating model retains protected compact recovery state rather than storing a second secret object the size of the payload.
Chapter 03 separates the classical FIPS-backed boundary from the optional post-quantum controls so customers can see precisely what is standardized, what is additive, and what is recorded in Trust.
Keep the standardized core explicit. Add post-quantum protection without hiding the stack.
ΞNIGMA treats classical and post-quantum cryptography as distinct layers with distinct jobs. The AWS-LC-backed classical path supplies the standardized protection around Trust, integrity, derivation and primary provenance; the PQC adjunct can add quantum-resistant encapsulation and signature paths around recovery and authentication without turning the implementation into a single opaque “PQC” claim.
Protect the Trust and recovery system with established primitives.
AES-256-GCM seals protected recovery material, GMAC supplies streaming ciphertext-integrity evidence, HKDF/SHA-384 handles derivation, and ECDSA-P384 provides the primary classical signing and provenance path.
Add quantum-resistant recovery and authenticity where the mission requires it.
ML-KEM can protect the K3Y encapsulation path, while ML-DSA and SLH-DSA provide independent post-quantum signature options. They supplement the classical boundary rather than obscuring or replacing it.
Chapter 04 shows how ΞNIGMA binds the Particle recovery state to required context, enforcement policy, integrity, provenance and cryptographic posture.
Trust defines the recovery contract. K3Y carries the protected state that can satisfy it.
ΞNIGMA separates recovery into two jobs. Trust records what the operation was, which context must match, and what integrity/provenance evidence belongs to it. K3Y protects the compact recovery state and can be governed independently from the ciphertext under the customer's own custody, IAM, retention and rotation model.
Recovery must satisfy the context committed when the data was protected.
Trust is more than metadata. It binds the operation identity, policy commitments, integrity evidence, provenance and cryptographic posture to the exact protection event. The three context fields deliberately do different jobs.
codesRequired + orderedThe committed authorization sequence must match.enforceRequired policyThe protected enforcement context must match.infoAudit-onlyMission or workflow context travels without becoming a decrypt gate.Keep recovery state governable without turning it into another payload-sized secret.
K3Y carries the protected compact recovery material needed to reconstruct the authorized Particle path. It can travel with ciphertext or remain separately held so custody can follow the customer's security model.
trust_id + qscc_idBind the record to the exact protection event and execution trail.Authorized Trust JSON exposes machine-readable evidence for SIEM, audit, compliance, provenance and operations without requiring plaintext recovery.
The Trust object turns cryptography into a readable security record.
Each protection event can carry a structured Trust record with identity, policy commitments, integrity, provenance, cryptographic posture and runtime evidence. Authorized /v1/unwrap can expose that Trust JSON without restoring payload bytes, giving the customer a clean path into SIEM, audit and compliance tooling.
Identity, policy, crypto posture, integrity, provenance and runtime evidence in one machine-readable record.
The SIEM story is broader than success/failure logging. Authorized Trust JSON can expose the operation identifiers, policy digests and audit-only info, integrity evidence, cryptographic configuration, verification identities, timestamps, bytes processed, wall time and measured throughput.
Encryption stops being opaque infrastructure.
The customer can correlate who protected what, under which policy, with which cryptographic posture, when it ran, and what integrity/provenance evidence was produced—without needing to recover plaintext.
trust_id · qscc_id · timestampBind security telemetry to a specific protection event and execution trail.codes_digest · enforce_digest · infoRequired commitments plus audit-only mission context.POST /v1/unwrap
{
"k3y_uri": "az://trust/audit.k3y",
"return": "trust_json",
"codes": ["7842", "11903"],
"enforce": "tenant:contoso policy:v3"
}
AUTHORIZED TRUST JSON
↓
SIEM · AUDIT · COMPLIANCE · PROVENANCEDesigned for machine ingestion rather than requiring a human to interpret opaque encrypted metadata.
Authorized Trust inspection can be performed through unwrap without restoring the protected payload.
Required gates and audit-only context remain distinguishable in the record.
Operational onboarding includes forwarding records to customer-controlled evidence systems.
Chapter 06 puts the same completed 1 PB outcome on both sides and exposes time, labor, platform, PQ, KMS/HSM and infrastructure carrying costs.
The economic advantage is the cost of reaching the same security outcome.
The model compares exactly the same 1 PB / 1,000,000 GB completed workload. ΞNIGMA uses the 20.28 GiB/s linear projection from three measured 6.76 GiB/s 8-vCPU workers; the illustrative assembled alternative remains at 384 MB/s and carries platform, PQ, KMS/HSM, people and recurring infrastructure allowances.
Not appliance price. The annual organization and infrastructure required to reach the same completed secure workload.
The alternative model includes platform, PQ / crypto-agility, KMS/HSM capacity, standing labor, active-run coverage, and recurring infrastructure. The cost is the operating system around the byte path, not just the runtime delta.
The alternative's labor burden alone approaches the cost of the entire ΞNIGMA model.
The modeled assembled alternative carries about $2.243M/year in standing + active-run people cost before platform, PQ, KMS/HSM and recurring infrastructure are added.
1,000,000 GB yields the modeled $3.0M encryption-platform line for the 1 PB workload.
Two-person active-run coverage across the modeled ~30.1-day completion window.
Modeled integration/crypto, audit/SRE, management and shared support burden.
The infrastructure allowance captures the cost of keeping the alternative stack supported and ready beyond the individual job window.
Chapter 07 closes the story with the operating model: URI-driven jobs, customer-controlled storage and key systems, governed K3Y destinations and Trust evidence forwarded into the customer's own security stack.
The control plane coordinates. The customer boundary carries the payload.
ΞNIGMA requests exchange JSON, object locations and key references rather than inline payload bytes. Customer-controlled storage, runtime identity, key systems, ciphertext, K3Y destinations and evidence forwarding remain part of the customer's operating model.
Reference the data. Execute near the data. Return governed outputs and evidence.
The service receives URIs and operation policy, resolves the permitted customer-controlled key references, performs the transform through the data plane, writes ciphertext and K3Y to selected destinations, and emits operational/Trust evidence for the customer's SIEM and audit workflows.
Keep the data, the key systems and the audit trail under your operating model.
ΞNIGMA is designed to be deployed as at-rest protection inside the customer boundary, not as a control plane that needs to ingest payload bytes.
Object-location driven execution keeps payload movement in the configured customer data path.
Key references preserve separation between job orchestration and customer-controlled key custody.
Trust can be bundled or separated to match customer IAM, retention, rotation and custody policies.
Operation and Trust records can feed SIEM, audit, compliance and provenance workflows.
Seven operating claims are now connected to the implementation underneath them.
The remainder of the site is reorganized as the technical evidence base: operating model, Particle path, FIPS/PQC stack, Trust/K3Y, APIs, threat model, economics, competition, engineering review and deployment quickstart.
Enter the full technical documentation ↓ΞNIGMA 3.0 · Complete Platform
ΞNIGMA 3.0 takes the operational idea people want from one-use encryption—fresh state for each protection event and an XOR transform across the whole object—without pretending that a compact seed is a message-length classical one-time pad. At the start of encryption, ΞNIGMA creates a new six-coordinate Particle Origin — x, y, z, r, p, t — from the FIPS-backed random-generation path. Those 384 random bits become the protected starting state for a deterministic, position-addressable Particle trace that produces the matching XOR stream across the payload. A new encryption does not carry forward an earlier Particle Origin, the source data is never used to create the stream, and ΞNIGMA does this without requiring a second payload-sized secret pad file to be stored, moved, synchronized, copied, or retained beside the ciphertext.
That is the deliberate trade. A classical OTP earns its perfect-secrecy theorem by requiring independent secret randomness at least as long as the message. ΞNIGMA gives up that information-theoretic claim and instead keeps compact protected recovery state. When recovery is authorized, it does not fetch a stored message-length pad; it restores the operation state and retraces the exact position-addressable Particle path, recreating the same computational stream only where it is needed and reversing the XOR back to the original data. Trust can travel with the ciphertext as one protected object or separately as a .k3y recovery capsule for independent keystore, IAM, custody, retention, and rotation.
ΞNIGMA then surrounds the Particle byte path with the rest of the modern cryptographic stack: SP 800-90A-backed random generation, a SP 800-90B review scope entropy-assurance path, AWS-LC-backed classical primitives, authenticated integrity and signatures, and optional post-quantum protection through ML-KEM, ML-DSA, and SLH-DSA. The result is not a claim to have compressed Shannon entropy. It is a full protection-and-recovery architecture: fresh per-operation Particle state for the data transform, Trust/K3Y for controlled recovery, and classical + PQC controls around the recovery path. What follows is the engineering detail behind that model.
Fresh per-operation origin. Stream on demand. Governed recovery.
ΞNIGMA changes the operating model around strong cryptography. Conventional at-rest systems usually apply a reusable symmetric key directly through a standardized block/stream cipher and then concentrate control in key management. ΞNIGMA moves the payload transform into a one-use Particle path: each encryption gets a newly randomized origin, the payload-matched XOR pad exists only while the bytes are being transformed, and the compact recovery state is authenticated, sealed, signed, policy-bound, and optionally post-quantum protected through Trust/K3Y.
| Layer | Conventional pattern | ΞNIGMA 3.0 | What changes operationally |
|---|---|---|---|
| Payload transform | Reusable AES/stream-cipher key drives the object cipher directly. | Fresh Particle origin drives a one-use, full-length XOR pad generated only as bytes are processed. | No payload-sized secret pad file and no designed path that carries a prior Particle origin into a new encryption. |
| Random origin | Long-lived data key or session key is the primary reusable secret. | Current build creates x,y,z,r,p,t with six independent FIPS-backed random draws for each encrypt operation. | The origin belongs to one protection operation and is recovered only through its Trust path. |
| Recovery | Possession of the data-encryption key is typically the central recovery condition. | Trust/K3Y carries the protected Particle recovery state plus integrity, policy, provenance, and signature evidence. | Recovery becomes an auditable, fail-closed contract rather than a bare key lookup. |
| Packaging | Ciphertext and key-management metadata are usually separate system concerns. | Trust can be bundled with ciphertext for portability or emitted as a separate .k3y for independent custody and lifecycle management. | Operators can choose portability or stronger administrative separation without changing the Particle data path. |
| Parallelism | Parallelization depends on the selected cipher mode and implementation. | The same Particle origin plus absolute position recreates the same 128-byte block, so workers can address disjoint ranges independently. | Direct seeking and parallel work do not require a shared mutable stream cursor. |
| Long-term crypto | Classical confidentiality and signatures are managed as separate modernization work. | AWS-LC-backed AES/HKDF/GMAC/ECDSA controls remain around Trust, with optional ML-KEM, ML-DSA, and SLH-DSA on the recovery/authentication path. | Particle, classical controls, PQC, policy, provenance, and evidence are delivered as one bounded platform. |
Fresh Origin. Full-Length Stream. No Pad File.
ΞNIGMA 3.0 transforms customer bytes with a Particle XOR stream generated from a new 384-bit Particle Origin State for each new encryption operation. That origin is assembled from six independent FIPS-backed random draws. Trust/K3Y carries the protected recovery state and may be bundled with the ciphertext or managed separately as a .k3y. AES-256-GCM seals the K3Y recovery path; it is not the primary byte cipher.
A classical one-time pad and ΞNIGMA are not making the same security claim. An ideal OTP can achieve information-theoretic perfect secrecy when its pad is uniformly random, independent of the message, at least as long as the message, kept secret, and never reused. ΞNIGMA does not claim that theorem. Particle starts from compact fresh random state and deterministically expands it into a position-addressable stream, so its confidentiality model is computational and seed-bound. What ΞNIGMA gains is operational: no message-length secret pad file, direct replay by absolute position, parallel range processing, compact recovery secrets, and a governed Trust/K3Y recovery architecture.
source URI + key refs + policyThe customer submits object locations, key references, policy gates, and identity to the data-plane service.M[i] ⊕ K[i] = C[i]Fresh per-operation state drives a deterministic stream that is consumed while the object bytes are transformed.state + policy + integrity + signaturesThe sealed recovery path carries protected operation state, integrity evidence, and policy commitments.cipher object + .k3yProtected output exits as governed artifacts: ciphertext at the object path and sealed recovery state at the K3Y path.Why not simply use a classical stored OTP?
A classical OTP is cryptographically remarkable precisely because it does not need a computational hardness assumption for confidentiality. Its cost is equally fundamental: the secret pad must contain at least as much independent randomness as the message. At cloud-object scale, that means managing a second secret object approximately the size of the protected data.
| Dimension | Classical ideal OTP | ΞNIGMA Particle | Operational consequence |
|---|---|---|---|
| Security category | Information-theoretic perfect secrecy when every OTP condition is satisfied. | Seed-bound computational security from fresh random origin state plus deterministic Particle generation. | ΞNIGMA does not claim to compress message-length Shannon entropy into 384 bits. |
| Secret material | Random secret pad at least as long as the plaintext. | 48-byte / 384-bit fresh Particle Origin (x,y,z,r,p,t). Trust/K3Y separately carries policy, integrity, provenance, signatures, and the protected recovery context. | The recovery secret stays compact relative to the payload; Trust integrity metadata can grow with chunk count, but ΞNIGMA does not create or retain a second message-sized secret pad. |
| 1 PB protected payload | Requires approximately 1 PB of secret random pad material, plus the protected payload itself. | Requires the compact Particle recovery secret plus the Trust/K3Y evidence needed to govern and verify the operation. | Eliminates message-sized secret-pad storage, movement, synchronization, and custody. |
| Recovery | Retrieve and align the original pad with the ciphertext. | Open the authorized K3Y state and regenerate the identical Particle stream at the required positions. | Recovery becomes a cryptographically governed operation rather than retrieval of a second payload-sized secret. |
| Random access / parallelism | Possible when the correct pad ranges are available and aligned. | The same protected origin plus absolute position recreates the same 128-byte Particle block, so disjoint ranges can be computed independently. | No shared mutable stream cursor and no requirement to fetch corresponding ranges from a stored pad object. |
| Policy / integrity / provenance | Not supplied by the OTP theorem itself; separate mechanisms are required. | Trust/K3Y binds recovery state to gates, GMAC integrity evidence, provenance, signatures, and optional PQC controls. | The byte transform and the recovery authorization system are delivered as one bounded architecture. |
N bytes of protected data, an ideal OTP needs at least N bytes of independent secret pad. ΞNIGMA intentionally trades that theorem for a compact, computationally generated stream and then uses Trust/K3Y to govern the recovery state.Cipher model
| Symbol | Meaning | Role |
|---|---|---|
M | Message / plaintext | Customer object bytes before transformation. |
K | Operation-specific Particle stream | Full-length XOR stream generated on demand from protected per-operation state and replayed only for authorized recovery; it is not a message-length store of independent random bits. |
C | Ciphertext | Protected object bytes written to customer-controlled storage. |
C = M ⊕ KM = C ⊕ KSecurity properties carried through the design
| Property | What the architecture enforces |
|---|---|
| Flexible Trust custody | Recovery material can travel inside a bundled protected object or be managed separately as a .k3y under independent IAM, retention, and rotation policy. |
| Customer boundary | The customer controls runtime placement, object locations, policy gates, and key systems. |
| Trust evidence | Signed provenance, integrity records, and auditable redacted Trust metadata document each operation. |
| Fresh origin per new encryption | Each new encryption samples a new Particle Origin State from six fresh random draws. The encrypt path contains no mechanism that intentionally carries forward an earlier origin; freshness is probabilistic, not a global uniqueness registry. |
| One operation / one Particle context | Each protected operation is bound to its own randomized origin, position-addressable stream, and authenticated recovery contract. |
Architecture flow
| Step | Element | Function |
|---|---|---|
01 | Object | Plaintext object remains in customer-controlled storage and is read inside the customer boundary. |
02 | Particle Origin | A new 384-bit Particle Origin is created for this encryption operation from six fresh FIPS-backed random coordinates. |
03 | XOR transform | The byte transformation applies C = M ⊕ K in a single reversible pass. |
04 | Trust / K3Y | The Particle Origin, Trust record, integrity evidence, policy, and provenance are authenticated and sealed as the operation's recovery context—bundled with the ciphertext or managed separately as .k3y. |
05 | Ciphertext | Protected bytes are written back to customer-controlled object storage. |
API & system boundary
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"
}| Byte path | Operation-specific Particle XOR stream |
|---|---|
| Recovery | Separate K3Y object and recovery path |
| Execution | Stateless operation inside the customer boundary |
| Evidence | Trust, integrity, status, and audit records |
| Reviewability | Verifiable outputs and automated validation artifacts |
Same pipeline, opposite direction.
The service is intentionally symmetric at the control level: it accepts object references, resolves the required key systems, validates the configured protections, and either exits with protected output or fails closed if the policy, trust, or signature checks do not line up. The difference is the direction of the byte flow.
| Stage | Encrypt | Decrypt |
|---|---|---|
| 01 · Entry | Read the plaintext object, destination URI, K3Y URI, and the policy / code inputs that govern the operation. | Read the ciphertext object, K3Y bundle, and the policy / code inputs required for authorized recovery. |
| 02 · Resolve | Resolve the configured vault/KMS references for AES-256-GCM, ECDSA-P384, and any optional PQC adjuncts. | Resolve the same recovery path and verification stack, then authenticate the sealed K3Y + Trust context before continuing. |
| 03 · Generate | Sample a fresh 384-bit Particle Origin from six random draws, then generate the position-addressable Particle stream required for the object as bytes are processed. | Recover the protected Particle Origin from the authenticated Trust/K3Y context and reconstruct the identical stream at the required absolute byte positions. |
| 04 · Transform | Apply C[i] = M[i] ⊕ K[i], compute ciphertext-integrity evidence, and produce ciphertext bytes for the object destination. | After Trust/K3Y authorization succeeds, verify ciphertext integrity as restoration proceeds and apply M[i] = C[i] ⊕ K[i]; failed verification prevents output commit. |
| 05 · Exit | Write ciphertext to the output object and keep the K3Y/Trust bundle in its governed recovery path. | Write recovered plaintext to the requested destination or return a hard failure when the verification gate fails. |
| 06 · Reject | Incorrect policy, wrong key references, or failed sealing results in a failed encrypt operation rather than a weaker cipher. | Incorrect codes, wrong enforce values, invalid signer context, or failed integrity checks reject the decrypt operation and stop plaintext recovery. |
Every protection event exits in one of two states only: valid protected output with a matching Trust/K3Y recovery path, or a fail-closed rejection before any plaintext is restored. There is no implicit downgrade, no intentional carry-forward of prior Particle state into a new encryption, and no successful output commit for a failed decrypt path.
valid refs + valid policyThe service accepts the request only when the object references, key systems, and policy gates are consistent with the operation.signatures + K3Y + MACsWrong signer context, mismatched UUIDs, wrong codes, or invalid integrity evidence stop the path before recovery proceeds.recreate stream from sealed bundleAuthorized recovery reconstructs the very same per-byte pad used by the original encryption event.ciphertext or failureThe path exits as either valid plaintext/ciphertext output or a hard cryptographic rejection; never as a mixed result.One job. Zero ambiguity.
ΞNIGMA 3.0 is a bounded cloud-at-rest encryption service. The request carries object and key references; payload bytes are read, transformed, and written inside the customer boundary; the K3Y recovery artifact remains separate from the ciphertext.
Operating contract
| Boundary | ΞNIGMA responsibility | Customer-controlled state |
|---|---|---|
| Coordinate | Accept a compact job manifest, validate supported URI/key-reference types, and orchestrate the requested operation. | Object locations, vault/KMS references, identity, policy values, and deployment configuration. |
| Transform | Read source bytes in-boundary, apply the operation-specific Particle XOR stream, produce integrity evidence, and write protected bytes to the destination object. | Source and destination storage accounts/buckets, network path, runtime placement, and access control. |
| Recover | Create and validate the separate K3Y Trust/recovery path required to reconstruct and authorize decryption. | K3Y location, required codes/enforce values, and the cryptographic references required for recovery. |
| Provision | POST /v1/keygen can provision the AES, signing, and configured PQC reference set used by later operations. | The resulting key material remains in customer-controlled vault/KMS systems; ΞNIGMA returns stable references rather than owning a central key registry. |
The machine that made secrecy move.
The historical Enigma turned cryptography into a repeatable machine process. A keypress sent an electrical signal through a configurable path; the machine produced one encrypted letter, advanced its internal state, and was ready to produce a different result on the next press.
How one keypress moved through the machine
| Stage | Element | What happened |
|---|---|---|
01 | Keypress | The operator selected one plaintext letter and closed the machine's electrical circuit. |
02 | Plugboard | Configured letter pairs were exchanged before the signal entered the rotor assembly. |
03 | Rotors | The signal crossed multiple wired rotors whose positions determined the substitution path for that moment. |
04 | Reflector | The signal was returned through the rotor stack, creating a second state-dependent path. |
05 | Lampboard + step | One ciphertext letter illuminated, then the rotor mechanism advanced and changed the state for the next character. |
Why the machine mattered
| Mechanized secrecy | Encryption became an operational procedure performed by a machine rather than a hand-built cipher table. |
|---|---|
| State was part of the cipher | Rotor order, rotor position, ring settings, plugboard configuration, and stepping behavior all influenced the result. |
| Operations mattered as much as mechanism | The system depended on controlled settings, disciplined procedures, and correct handling of the information required to reproduce the state. |
What ΞNIGMA 3.0 carries forward — and what changes
| Design idea | Historical Enigma | ΞNIGMA 3.0 |
|---|---|---|
| Unit of transformation | Alphabetic character | Cloud object byte stream |
| Changing state | Mechanical rotor position changed as characters were entered | Fresh operation-specific Particle seed material establishes a new transformation path for each encryption operation |
| Transformation mechanism | Electro-mechanical substitution through plugboard, rotors, and reflector | Position-addressable Particle XOR transformation inside the customer boundary |
| Recovery dependency | Matching machine configuration and message settings | Corresponding K3Y recovery path, policy gates, and configured cryptographic controls |
| Evidence | Primarily procedural and operator-managed | Trust metadata, integrity records, signatures, status output, and automated validation artifacts |
The original Enigma made secrecy mechanical. ΞNIGMA 3.0 does not reproduce the rotor cipher; it carries forward the systems principle that protected information is governed by controlled state, disciplined separation, and a deliberately managed recovery path.
Measured cryptographic throughput.
Azure Cobalt ARM 100 benchmark profile using a 16 MB chunk and a 10.38 GiB payload, with the FIPS core, K3Y seal path, and optional post-quantum adjuncts represented in the platform benchmark configuration.
Benchmark profile
| Platform | Chunk | Payload | Execution boundary |
|---|---|---|---|
| Azure Cobalt ARM 100 | 16 MB | 10.38 GiB | Customer boundary |
Throughput by allocated vCPU
| vCPU | Encrypt | Decrypt | Benchmark observation |
|---|---|---|---|
| 2 | 1.56 GiB/s | 1.46 GiB/s | Small-worker baseline. |
| 4 | 3.59 GiB/s | 3.31 GiB/s | Strong scale-up from the 2-vCPU profile. |
| 8 | 6.76 GiB/s | 7.92 GiB/s | Highest measured decrypt throughput in this profile. |
| 10 | 8.14 GiB/s | 7.57 GiB/s | Highest measured encrypt throughput in this profile. |
Measured worker basis: 6.76 GiB/s encrypt per 8-vCPU Cobalt worker. Three independent 8-vCPU workers provide a 20.28 GiB/s aggregate throughput projection when jobs or byte ranges scale linearly across workers. That is 24 vCPU total. At the projected aggregate rate, a 1 PB workload represents about 12.76 hours of raw cryptographic work. The 20.28 GiB/s figure is a cluster projection from three measured single-worker results, not a separately measured three-node benchmark.
Measured operating markers
| Peak encrypt | 8.14 GiB/s at 10 vCPU |
|---|---|
| Peak decrypt | 7.92 GiB/s at 8 vCPU |
| K3Y seal | ~6 ms |
| Memory delta | +9 MB RSS / job |
| Blob egress note | ~0.47–0.57 GiB/s ceiling |
| 8+ vCPU note | Recorded as write-bound |
Cryptographic configuration represented
| Layer | Components |
|---|---|
| FIPS core | AES-256-GCM ECDSA P-384 HKDF-SHA-384 |
| Post-quantum adjunct | ML-KEM-768 ML-DSA-65 SLH-DSA-128s |
| ΞNIGMA data path | Particle XOR K3Y capsule Codes / policy gates |
Cryptographic throughput and storage-path throughput are separate constraints. The compute path scales strongly through the measured worker sizes, while the benchmark notes that the workload becomes write-bound at 8+ vCPU and records blob egress at roughly 0.47–0.57 GiB/s. The table above therefore preserves the cryptographic measurements separately from the cloud I/O ceiling.
Cloud deployment surface.
At-rest encryption inside your boundary.
ΞNIGMA 3.0 is deployed into customer-controlled cloud or approved compute infrastructure. The service coordinates work from object-storage pointers and customer-owned key references, performs the byte transformation inside that boundary, and writes the ciphertext and separate K3Y recovery path back to locations the customer controls.
Cloud objects when the data already lives in storage. Direct bytes when ΞNIGMA lives inside the application.
The cryptographic and Trust model does not change. What changes is who owns I/O and key resolution. In cloud deployment, the REST service receives object and key references and performs the work inside the customer runtime. In native integration, application code calls the Rust crate directly with byte readers/writers and in-process key material.
URI in. URI out. Keys stay referenced.
Use REST/JSON when the source is a Blob/S3/GCS object and key custody stays in Vault/KMS/HSM. The service resolves the references, streams the object through Particle, writes ciphertext and K3Y separately, and emits Trust evidence for the SIEM/audit path.
az://s3://gcs://kv://kvk://REST / JSONRead + Write in. Ciphertext + K3Y out.
Use the crate when ΞNIGMA is embedded directly in a Rust service, agent, pipeline, appliance, or test harness. The caller owns the byte stream and passes AES/signing/PQC material plus codes, info, and enforce directly into the core options.
core::encryptcore::decryptcore::reencryptunwrap_bind_infostdin/stdout CLIDeployment surface
| Surface | Customer-controlled resource | ΞNIGMA action | Boundary rule |
|---|---|---|---|
| Object storage | Blob / S3 / GCS object locations | Read source bytes and write protected output. | Payload objects remain in customer-selected storage. |
| Key systems | Vault / KMS / HSM references | Resolve encryption, signing, unwrap, and optional PQC material by reference. | Key ownership and access policy remain with the customer. |
| Workload identity | Managed identity / workload role | Authorize least-privilege read, write, sign, and unwrap operations. | No reusable cloud-account secret is required by the service. |
| Private runtime | Approved VM, container, VPC, VNet, or cluster boundary | Execute the encrypt / decrypt job close to customer data. | Protected payload bytes do not need to traverse an external control plane. |
| K3Y path | Customer-selected separate storage location | Write the sealed recovery capsule and Trust material separately from ciphertext. | Recovery material is not stored as part of the ciphertext object. |
In-boundary data path
| Stage | Operation | What moves | Control |
|---|---|---|---|
REQUEST | Submit job manifest | Object URIs, key references, policy inputs, job metadata | REST authorization + entitlement |
READ | Open source object | Plaintext bytes inside the customer runtime boundary | Customer workload identity |
RESOLVE | Load cryptographic references | Vault / KMS / HSM material required for the configured path | Customer key policy |
TRANSFORM | Encrypt or decrypt | Streaming bytes through Particle XOR plus configured integrity / recovery controls | In-boundary compute |
WRITE | Persist artifacts | Ciphertext to one location; K3Y to its separate location | Customer-selected destinations |
The control plane coordinates; the customer data plane carries the payload. Storage locations, runtime placement, key systems, identity policy, ciphertext, and K3Y destinations remain under customer control.
object URIs + key refs + policyCustomer requests identify source bytes, destination bytes, key systems, and the K3Y recovery path.read → XOR → integrityBytes are read, transformed, and validated inside the customer runtime before exit is authorized.Trust / K3Y / gatesRecovery is sealed with the configured keys, signatures, and required policy commitments.ciphertext + K3YThe object path and recovery path are separated by design, and both remain under customer control.10-Step Onboarding to Production
The production path moves from cloud foundation to identity and key access, then through validation, evidence collection, and controlled go-live. The sequence below belongs to the deployment surface because every step establishes or verifies something inside the customer boundary.
| Step | Phase | Action | Production check |
|---|---|---|---|
| 01 | Foundation | Create or designate the subscription. Select the Azure subscription and resource boundary that will contain the deployment. | Ownership, region, policy, and billing scope are established. |
| 02 | Foundation | Deploy ΞNIGMA 3.0. Place the runtime on the approved VM, AKS, Container Apps, or equivalent private compute surface. | Runtime is reachable only through the intended network path. |
| 03 | Identity | Assign workload identity. Grant least-privilege access to the required storage and key systems. | Read, write, sign, and unwrap permissions are scoped to required resources. |
| 04 | Keys | Provision cryptographic references. Generate or import AES, ECDSA, and permitted PQC material; retain customer control of the key systems. | Stable Vault / KMS / HSM references resolve from the runtime identity. |
| 05 | Validation | Stage representative test data. Place a non-production sample object in the same storage pattern intended for production jobs. | Source and destination URIs exercise the real data-plane path. |
| 06 | Validation | Run health and readiness checks. Call /v1/health and confirm version, FIPS posture, entitlement state, and configured limits. | Service reports ready before protected operations are enabled. |
| 07 | Validation | Submit the first protected job. Run an encrypt operation through /v1/job using the production-style object and key references. | Job completes successfully inside the intended customer boundary. |
| 08 | Evidence | Verify the roundtrip and artifacts. Confirm ciphertext output, separate K3Y, Trust metadata, gates, signatures, and integrity verification. | Decrypt restores the source bytes and validation evidence is retained. |
| 09 | Operations | Connect logging and metering. Forward operational records to the customer SIEM / audit path and enable authorized metering integrations as required. | Security, job, failure, and usage events reach the approved evidence systems. |
| 10 | Go-live | Enable production policy. Apply quotas, entitlement gates, alerting, recovery procedures, and change-control requirements. | Production acceptance criteria are documented and monitoring is active. |
Go-live follows a verified roundtrip, not merely a successful deployment. The customer should be able to prove storage access, key resolution, encrypt/decrypt correctness, K3Y separation, Trust verification, logging, and failure handling before production policy is enabled.
Particle XOR Layer — Not AES-at-Rest
The customer byte stream is transformed by a fresh, per-operation Particle XOR keystream. AES-256-GCM is used on the separate K3Y recovery path rather than as the primary byte cipher for the object itself. The current Particle Origin State is 384 bits / 48 bytes, created as six independently randomized 64-bit words: x, y, z, r, p, t.
Particle XOR transforms the object bytes. AES-256-GCM seals K3Y recovery material. Optional PQC controls protect the recovery/authentication path. These are distinct roles in the stack.
Particle state construction
| Stage | Representation | Purpose |
|---|---|---|
| Random origin | 6 × u64 = 384 bits / 48 bytes | Each of x, y, z, r, p, t is created by a separate call to the FIPS-backed random source when the encrypt operation begins. |
| ParticleKey | 6 × u64x · y · z · r · p · t | The six random coordinates form the compact per-operation recovery/origin state used to reproduce the Particle path. |
| Schedule | HKDF-SHA-384 | The 48-byte randomized origin is input to a small domain-separated schedule that derives four internal 64-bit subkeys. HKDF is part of the replayable schedule; it is not the source of the six random Particle coordinates. |
| Addressing | block index i | Each output block is derived from seed/state plus its position, allowing disjoint chunks to be processed without shared mutable stream state. |
| Transform | C[i] = M[i] ⊕ K[i] | The generated keystream block is XORed with the corresponding plaintext bytes; raw keystream bytes are not emitted as output. |
O = { x, y, z, r, p, t }
6 independent FIPS-backed random draws · 384 bits in the current build
S[i] = ParticleState(O, i)
The origin + absolute position identifies the exact state needed for that portion of the payload
K[i] = Emit(S[i])
128-byte pad blocks are created only when needed; authorized decrypt recreates the same block at the same position
C[i] = M[i] ⊕ K[i]
Recovery applies the same pad again: M[i] = C[i] ⊕ K[i]
Design properties
| Property | Implementation intent |
|---|---|
| Fresh per operation | A new Particle Origin State is sampled from six random draws for each new encryption operation; the encrypt path does not intentionally carry forward a prior origin. |
| Position-addressable | Workers can derive the keystream for their assigned byte range without coordinating a shared mutable cursor. |
| Keystream not persisted | Generated stream bytes are transient transformation material; only the resulting ciphertext is written to the object path. |
| Trust packaging is selectable | The protected recovery state can be bundled with ciphertext or emitted separately as .k3y; separated mode enables independent custody and lifecycle policy. |
| Recovery is gated | K3Y opening, policy gates, signatures, and configured cryptographic controls determine whether the seed/recovery path can be used. |
ΞNIGMA has one payload transform: Particle. Every new encryption independently samples one fresh 48-byte / 384-bit Particle Origin. That origin drives the deterministic, position-addressable stream used across the object. The generated stream exists only as transient working material; the protected origin is retained in Trust/K3Y so authorized recovery can retrace the identical stream later. There is no second Particle mode and no message-length secret pad file.
The byte layer is Particle XOR.One engine. One 384-bit origin. Compact recovery state. Sealed K3Y.
ΞNIGMA separates the customer-byte transformation from the recovery and trust path. There is one Particle data engine. Each new encryption independently creates a fresh 48-byte / 384-bit Particle Origin — x, y, z, r, p, t — and uses that origin to generate a deterministic, position-addressable XOR stream as the payload moves through the service. The expanded stream is transient. Trust/K3Y protects the compact origin and the evidence required to authorize and verify recovery.
A classical OTP stores secret random material at least as long as the message. Particle does not. Particle begins with compact fresh random state and deterministically generates the full-length stream from that state, so ΞNIGMA makes a computational-security claim rather than an information-theoretic perfect-secrecy claim. That trade removes the message-sized secret-pad requirement while preserving a fresh per-encryption origin, full-object XOR transformation, direct positional replay, and exact reversible recovery.
One Particle construction
| Element | Representation | What it does | What persists |
|---|---|---|---|
| Particle Origin | 48 bytes / 384 bitsx · y · z · r · p · t | Six independently randomized 64-bit coordinates establish the per-encryption starting state. | The protected origin is carried by the Trust/K3Y recovery context. |
| Particle stream | K[i] = Particle(origin, i) | Absolute byte position selects the deterministic stream range needed for that part of the object. | No payload-length stream file is retained. |
| Encrypt | C[i] = M[i] ⊕ K[i] | Generated stream bytes are XORed with plaintext as the object is processed. | Ciphertext plus the governed K3Y recovery artifact. |
| Recover | M[i] = C[i] ⊕ K[i] | Authorized decrypt restores the same origin and retraces the exact stream at the same positions. | Recovered plaintext is committed only after the configured recovery and integrity gates succeed. |
x · y · z · r · p · tNew encryption starts from six fresh FIPS-backed random draws.C[i] = M[i] ⊕ K[i]The engine computes only the stream ranges needed for the bytes being processed; generated stream bytes remain transient.cipher object + protected originThe ciphertext and compact recovery context can be packaged together or governed separately.Particle, Trust, and K3Y have separate jobs
| Layer | Job | Why the separation matters |
|---|---|---|
| Particle | Transforms customer bytes with the operation-specific, position-addressable XOR stream. | The payload path does not depend on storing a message-sized secret pad and AES is not the primary object cipher. |
| Trust | Records the protected Particle recovery state, integrity evidence, policy commitments, provenance, identity, and telemetry. | Recovery is an authenticated contract rather than possession of a bare data key. |
| K3Y | Seals and governs the Trust/recovery context with the configured classical and optional PQC controls. | The recovery object can be independently protected, retained, rotated, audited, and separated from ciphertext. |
Classical OTP vs. Particle, precisely
| Property | Classical ideal OTP | ΞNIGMA Particle |
|---|---|---|
| Secret size | Secret random pad at least as long as the payload. | One protected 48-byte / 384-bit Particle Origin plus Trust/K3Y metadata and integrity evidence. |
| Secrecy model | Information-theoretic perfect secrecy when every OTP condition is satisfied. | Seed-bound computational security; confidentiality depends on origin freshness/secrecy and the security of the Particle construction and recovery controls. |
| Expanded stream | The pad itself is the secret and must be retained or delivered securely for recovery. | The expanded Particle stream is generated as needed and discarded; it is reconstructed from the protected origin for authorized recovery. |
| 1 PB payload | Approximately 1 PB of independent secret pad material is required. | No second 1 PB secret pad object is created; the Particle origin remains 48 bytes, with separate Trust/K3Y evidence. |
| Random access | Requires locating and aligning the corresponding secret pad range. | Absolute position directly addresses the corresponding Particle stream range. |
| Governance | Integrity, identity, provenance, and policy are outside the OTP theorem and must be added separately. | Trust/K3Y integrates those controls around the Particle recovery path. |
The classical OTP solves secrecy by preserving message-length secret randomness. Particle solves a different systems problem by preserving origin. ΞNIGMA creates fresh random state for every new encryption, turns that state into a full-length position-addressable stream only as computation, discards the expanded stream, and protects the compact origin inside a governed recovery architecture. That is the core design choice.
Every new encryption starts with a fresh Particle Origin.
No prior-origin reuse path.
Keystream reuse is treated as a hard design failure. Each new encryption independently samples a fresh Particle Origin State and produces a new Trust/K3Y recovery context. The encrypt path does not intentionally carry a prior origin forward. Re-encryption is a different operation: it can deliberately preserve the existing Particle state because the ciphertext bytes are not transformed again.
Why reuse is unacceptable
C₁ = M₁ ⊕ K
C₂ = M₂ ⊕ K
C₁ ⊕ C₂ = M₁ ⊕ M₂
The ciphertext pair now exposes a direct relationship between the two plaintexts.
Every independent new encryption operation begins by sampling fresh Particle origin state and creating a new Trust/K3Y recovery context. Reusing the same XOR stream across two different plaintexts would expose M₁ ⊕ M₂ when the ciphertexts are XORed, so the implementation contains no intentional path for carrying a prior origin into a new encryption. This is a randomness-based freshness guarantee, not a global database claiming that a 384-bit random collision is mathematically impossible.
Per-encrypt lifecycle
| Step | Control | What happens for each encryption operation |
|---|---|---|
| 01 | Fresh Particle origin | A new 6 × u64 / 384-bit Particle Origin State is assembled from six independent draws from the configured FIPS-backed random-generation path. |
| 02 | Position-addressable Particle state | The origin and absolute byte position drive the Particle schedule so the required pad block can be generated on demand and reproduced exactly for authorized recovery. |
| 03 | Trust identity | The operation receives its own provenance identifiers, including trust_id and qscc_id, binding recovery state, integrity evidence, policy, and execution evidence to that operation. |
| 04 | Trust/K3Y recovery context | The Particle recovery state and Trust record are authenticated and sealed by the configured K3Y protection controls. |
| 05 | Packaging choice | The sealed recovery context can travel bundled with the ciphertext or as a separately governed .k3y artifact for independent custody, IAM, retention, and rotation. |
| 06 | Next operation | The next independent encryption creates a new Particle origin and a new Trust/K3Y context rather than carrying forward the prior operation's pad state. |
One operation, one recovery context
{x,y,z,r,p,t} · 384 bits
Six fresh FIPS-backed random coordinates independently sample the origin for this operation; the new-encrypt path does not carry forward an existing origin.
trust_id · qscc_id
Integrity, policy, provenance, signatures, and execution evidence are bound to the same operation.
Trust / K3Y
Authenticate and seal the recovery state, then carry it with the ciphertext or manage it separately as .k3y.
Harvest-now / decrypt-later review
| Material captured | What is still required | Review implication |
|---|---|---|
| XOR ciphertext only | The corresponding Particle Origin State / authorized recovery context. | SEPARATED — the Particle Origin State is not exposed as plaintext inside the ciphertext object. |
| Ciphertext + K3Y | Successful opening of the configured K3Y protection path and satisfaction of the required policy gates. | KEY-BOUND — long-term confidentiality therefore depends on protecting the K3Y seal and its configured key systems. |
| Two independently encrypted copies | Reuse of the same Particle stream would be the dangerous condition. | FRESH-CONTEXT DESIGN — each encrypt begins with a new Particle Origin rather than reusing a prior stream context. |
| Trust signature material | Forgery of provenance is distinct from recovery of the Particle Origin State or plaintext. | SEPARATE ROLE — signatures attest operation evidence; they are not the byte-recovery secret. |
Control summary
| Control objective | Review posture |
|---|---|
| Origin freshness | Generate a new Particle Origin State from six independent random draws at the start of each encrypt operation. |
| No reusable data key | Do not treat the Particle Origin State as a long-lived AES-style data key shared across objects or jobs. |
| K3Y separation | Keep recovery material on a separate sealed path from the XOR ciphertext. |
| Operation provenance | Bind Trust evidence to the operation through identifiers and integrity/signature records. |
| Fail-closed recovery | Require the corresponding K3Y path and configured gates/cryptographic controls before recovery succeeds. |
Fresh new encryption. Fresh independently sampled Particle state. Distinct Trust/K3Y recovery context. Particle generates the stream only when it is needed and authorized recovery replays the same operation-specific bytes. The critical invariant is no intentional reuse of a prior stream context across independent new encryption operations. Metadata-only re-encryption is explicitly different because it rotates recovery protection around unchanged ciphertext and therefore preserves the existing Particle state.
FIPS Cryptographic Stack
The standardized cryptographic boundary is kept deliberately narrow. AWS-LC, accessed through aws_lc_rs, supplies the classical primitives used for sealing, integrity support, derivation, signatures, hashing, and randomness. ΞNIGMA orchestration sits above that boundary; the optional post-quantum adjunct remains a separate layer.
Classical primitive map
| Primitive | Role | Use in ΞNIGMA | Boundary status |
|---|---|---|---|
| AES-256-GCM | K3Y / Trust sealing | Authenticates and encrypts the recovery capsule. Associated data binds the required policy commitments to the protected Trust state. | AWS-LC CORE |
| HKDF + SHA-2 | Domain-separated derivation | Supports Particle schedule derivation and dedicated integrity-key derivation. SHA-256 is also used for policy and evidence commitments. | AWS-LC CORE |
| ECDSA P-384 / SHA-384 | Primary Trust signature | Signs operation evidence and provenance. A secondary P-384 signing path can be configured independently. | AWS-LC / KEY VAULT PATH |
| Random generation | Fresh seed, nonce, key material | aws_lc_rs::rand::SystemRandom supplies runtime randomness used by the classical security path. | AWS-LC CORE |
| GMAC | Chunk-level ciphertext integrity | Authenticates ciphertext chunks with a dedicated derived MAC key; resulting evidence is committed into Trust. | AES-GCM AUTH PATH |
What is inside — and outside — the boundary
| Layer | Responsibility | Review posture |
|---|---|---|
| Standardized cryptography | AES-GCM, SHA-2/HKDF, P-384 signing support, and runtime randomness. | CRYPTO BOUNDARY — provided through the AWS-LC-backed path. |
| Particle byte transform | Position-addressable operation-specific XOR stream generated on demand and applied to customer payload bytes. | APPLICATION CONSTRUCTION — custom ΞNIGMA Particle stream layer, separate from the standardized FIPS primitive boundary and not presented as a classical OTP primitive. |
| K3Y + Trust | Recovery format, evidence schema, integrity records, identifiers, policy commitments, and artifact separation. | APPLICATION PROTOCOL — protected by the standardized primitives above. |
codes / enforce | Fail-closed policy inputs committed into authenticated recovery state. | POLICY LAYER — application semantics enforced through authenticated cryptographic state. |
| PQC adjunct | Optional ML-KEM, ML-DSA, and SLH-DSA protection around K3Y confidentiality and Trust authentication. | SEPARATE LAYER — documented independently in the next section. |
Runtime assurance
| Control | What is checked | Why it matters |
|---|---|---|
| FIPS runtime posture | AWS_LC_RUST_FIPS=1 is required for the intended FIPS-enabled execution posture. | Prevents the reviewed deployment path from silently running in an unintended provider mode. |
| Known-answer / diagnostic checks | Internal diagnostics exercise the configured classical primitives and report failures explicitly. | Provides release and deployment evidence that the configured cryptographic path is operational. |
| Fail-closed inputs | Invalid keys, malformed material, mismatched policy commitments, and incomplete recovery state are rejected before plaintext is released. | Keeps cryptographic success and authorization success coupled at recovery time. |
| Key ownership | Customer-controlled vault/KMS references and caller-supplied key material remain external to the service's long-lived state. | Separates the application from persistent customer key custody. |
Implementation posture is not the same thing as an independent product certificate. This section describes the AWS-LC-backed cryptographic boundary and the runtime controls used by the current build. Any formal module/product validation or deployment authorization remains an external assessment process and should be represented separately.
Post-Quantum Cryptography Adjunct
The post-quantum layer is an optional protection path around K3Y confidentiality and Trust authentication. It augments the AWS-LC-backed classical/FIPS core; it does not replace the Particle byte transform, AES-256-GCM sealing, GMAC integrity, or the primary ECDSA-P384 Trust signature.
Post-quantum control map
| Control | Standard / family | What it protects | How it is used |
|---|---|---|---|
| Kyber-768 / ML-KEM-768 family | Kyber lineage / FIPS 203 mapping Module-LWE | K3Y confidentiality and the long-term recovery path. | Encapsulates a shared secret to the recipient public key; a derived KEK protects the K3Y capsule. Used when the PQC adjunct is enabled. |
| Dilithium3 / ML-DSA family | Dilithium lineage / FIPS 204 mapping Module-lattice signature | Trust authenticity under a post-quantum signature path. | Adds an independent PQ signature over Trust material; decrypt/unwrap verifies it when configured. |
| SPHINCS+ SHA2-128s-simple / SLH-DSA family | SPHINCS+ lineage / FIPS 205 mapping Hash-based signature | Independent Trust authenticity using a non-lattice assumption. | Adds a second optional PQ signature path; verification is required when that path is configured for the operation. |
| ECDSA-P384 | FIPS 186-5 Classical signature | Primary Trust authenticity in the classical/FIPS core. | Remains the primary Trust signature; PQ signatures supplement rather than silently replace it. |
Where PQC sits in the recovery path
Operational contract
| State | Expected behavior | Review implication |
|---|---|---|
| PQC disabled | The classical/FIPS path remains responsible for K3Y sealing, Trust signing, integrity, and recovery authorization. | Do not describe the operation as having post-quantum K3Y or signature protection. |
| PQC enabled for encrypt | K3Y is protected with the configured ML-KEM recipient path; configured PQ Trust signatures are emitted with the operation. | Trust should identify the enabled adjuncts so the resulting artifact is auditable. |
| PQC required for decrypt / unwrap | The corresponding private/verification material must be supplied and all configured PQ checks must pass before recovery or authorized Trust release. | Missing or invalid required PQ material is a fail-closed condition. |
| Mixed deployment | Classical and PQ controls can coexist while customers migrate policy, keys, and workloads. | The security claim must follow the controls actually enabled for that operation—not merely the features compiled into the build. |
The adjunct protects the K3Y/Trust recovery path; it is not a claim that every layer becomes post-quantum merely because the feature is present. In the current architecture, PQC operations use the separate oqs/liboqs path and are identified accordingly in Trust, while the AWS-LC-backed classical core remains the FIPS boundary. Review should verify which adjuncts were actually enabled and enforced for the operation.
K3Y Trust Capsule
K3Y is the authenticated Trust and recovery capsule associated with a protected payload. It carries the Particle recovery state, Trust record, integrity evidence, policy commitments, and provenance needed to authorize and reconstruct recovery. ΞNIGMA supports two packaging modes: the sealed Trust capsule can be bundled with ciphertext for portable single-object handling, or emitted as a separate .k3y artifact for independent keystore, IAM, retention, custody, and rotation management.
Recovery contract
| Element | What it carries | Role in recovery |
|---|---|---|
| Ciphertext | Particle-XOR-transformed payload bytes. | Protected data artifact. It may travel alone with Trust managed separately, or as the payload portion of a bundled protected object. |
| Trust / K3Y | Sealed Particle recovery state, Trust/provenance fields, policy commitments, and ciphertext-integrity evidence. | Provides the authenticated recovery state corresponding to the ciphertext; it can be bundled or independently managed as .k3y. |
| Cryptographic controls | AES-256-GCM key reference, signing verification material, and optional PQC key material. | Open, authenticate, and verify the K3Y path according to the configured stack. |
| Policy gates | codes and enforce must match their committed values. info remains audit metadata. | Incorrect required gates fail closed; audit-only info can differ without becoming a decrypt gate. |
Packaging does not change the recovery contract. Whether Trust is bundled with ciphertext or managed separately as .k3y, successful recovery still requires the corresponding protected Trust state, the configured cryptographic key controls, and every required policy gate.
Trust Payload
The Trust payload is the compact operating record sealed for one encryption event. It binds Particle recovery state, policy, integrity, identity, provenance, and execution evidence to the protected payload. That sealed Trust can be packaged inline with the ciphertext or managed independently through the .k3y path.
| Record family | Fields | What the record establishes |
|---|---|---|
| Recovery secret | arng_key | Protected 48-byte Particle Origin (6 × u64). Authorized decrypt restores this state from Trust/K3Y and replays the same position-addressable Particle stream. |
| Classical identity | pk_primarypk_secondary | Primary and optional secondary ECDSA-P384 verification identities for Trust provenance. |
| PQ identity | pqc_kem_pubpqc_sig_pubpqc_slh_sig_pub | Optional ML-KEM/Kyber recovery identity and ML-DSA / SLH-DSA receipt metadata when the PQ adjunct is enabled; these fields can be verified later as part of the sealed Trust path. |
| Policy commitments | codes_digestenforce_digest | SHA-256 commitments to the ordered authorization codes and required enforcement policy without storing the original gate values as plaintext fields. |
| Ciphertext integrity | ct_gmac_chunksGMAC digest metadata | Per-chunk integrity evidence used to detect modified, missing, reordered, or substituted ciphertext during recovery. |
| Execution evidence | qscc_* | Bytes processed, timing, throughput, integrity timing, and operation telemetry. |
| Operation identity | trust_idqscc_idtimestamp_ns | Identifiers and timing that bind the Trust record to a specific operation and measurable execution trail. |
| Protection layer | Protects | Review point |
|---|---|---|
| ECDSA-P384 | Trust provenance and classical signature verification. | Verify the expected signing identity before authorized Trust/recovery release. |
| AES-256-GCM | Confidentiality and authentication of the sealed Trust/recovery payload. | Wrong key material or mismatched authenticated policy state causes open/authentication failure. |
| GMAC chain | Integrity of the ciphertext stream represented inside Trust. | Chunk tags are checked during decrypt; the aggregate digest gives a compact integrity commitment. |
| Optional PQC adjunct | Longer-lived K3Y recovery and authentication path. | ML-KEM/Kyber wrap and ML-DSA / SLH-DSA verification apply only when configured. |
Bundled or Separate Trust Packaging
ΞNIGMA separates the payload role from the Trust/recovery role even when both are carried in one bundle. Operators can keep ciphertext and .k3y as independent artifacts for stronger keystore separation, or bundle the sealed Trust capsule with ciphertext when portability and single-object handling are more useful.
| Dimension | Ciphertext | K3Y |
|---|---|---|
| Primary purpose | Carry the protected payload bytes. | Carry authenticated recovery, policy, integrity, and provenance state. |
| Contains | Particle-XOR-transformed object bytes. | Sealed Particle recovery state, Trust metadata, gate commitments, signatures/identity, and integrity evidence. |
| Packaging | Can remain a standalone ciphertext object or be packaged with the sealed Trust capsule. | Can be bundled inline with ciphertext or emitted separately as .k3y. |
| Storage policy | Customer-selected filesystem, object store, appliance, or application destination. | When separate, can use tighter IAM, keystore, retention, escrow/custody, and rotation policy than the payload object. |
| Exposure model | Standalone ciphertext does not expose the protected Particle recovery state. | A bundled object still keeps Trust cryptographically sealed; a separate .k3y additionally creates an administrative separation boundary. |
| Rotation / re-encryption | Can remain unchanged when the workflow rotates K3Y protection and policy state around the same ciphertext. | Recovery controls, gate state, and sealing material can be re-issued through the re-encryption workflow. |
Bundling and separation are deployment choices, not different cryptographic modes. Bundling simplifies transport and object handling because ciphertext and sealed Trust move together. A separate .k3y adds an administrative and custody boundary so recovery state can live under different IAM, keystore, retention, and rotation controls. In either form, the Trust state remains cryptographically sealed and recovery remains subject to the configured keys and required gates.
End-to-End Encryption Flow
One encryption operation coordinates two distinct outputs: the protected object bytes and the separate K3Y recovery artifact. Each control has one job—transform the payload, authenticate the ciphertext, construct Trust, protect recovery state, and optionally add post-quantum protection.
Ciphertext follows the object-storage path. Seed and Trust recovery state follow the separate K3Y path.
Encryption Control Path
| Stage | Control | Input → output | What is established |
|---|---|---|---|
01 | Resolve operation context | Object URIs + key references + policy context | The source, destination, K3Y location, required gates, signing identity, and optional PQC references are fixed before protected work begins. |
02 | Generate + transform | Plaintext + fresh 384-bit seed → ciphertext | A fresh per-operation Particle seed drives the position-addressable XOR stream. The keystream is applied to the payload bytes; raw seed and keystream are not emitted with the ciphertext. |
03 | Commit integrity | Ciphertext chunks → GMAC evidence | Per-chunk GMAC tags and the integrity summary are generated over the ciphertext and committed into Trust for later verification. |
04 | Build + seal Trust | Seed + integrity + provenance + gates → K3Y | Trust is assembled, signed with the configured ECDSA-P384 identity, and protected by AES-256-GCM with the required gated context bound to the recovery path. |
05 | Apply optional PQC adjuncts | K3Y / Trust → PQ-protected recovery state | When configured, ML-KEM protects the K3Y recovery path and ML-DSA / SLH-DSA add independent post-quantum authentication evidence. |
What the Operation Emits
plaintext ⊕ Particle stream → ciphertext
Protected payload bytes are written to the customer-selected object destination. The Particle seed is not stored with this object.
seed + Trust + integrity + gates → protected K3Y
The recovery artifact is written separately so its IAM, retention, key access, and policy controls can be governed independently from the ciphertext.
| Output | Contains | Does not contain | Recovery role |
|---|---|---|---|
| Ciphertext | Particle-transformed payload bytes | Raw Particle seed, private keys, plaintext | Provides the protected data object that must be paired with its corresponding recovery path. |
| K3Y | Protected Trust, seed recovery state, integrity commitments, provenance, and policy context | The ciphertext payload itself | Provides the protected state needed to authorize, verify, and reconstruct recovery. |
Restored plaintext is committed only after the corresponding K3Y path, required gates, configured signatures, and ciphertext-integrity evidence validate. The decrypt path is deliberately fail-closed: recovery authorization is established from Trust/K3Y first, ciphertext integrity is verified as part of restoration, and the output sink is not committed on a failed operation. The patched core path additionally verifies each ciphertext chunk before that chunk is released to the plaintext writer.
Two ways to call ΞNIGMA. Same Particle + Trust core.
Cloud/object mode is a REST control plane over customer storage and customer key URIs. Native byte mode is the Rust crate itself: the application supplies readers, writers, key bytes, policy context, and receives ciphertext/K3Y/Trust directly. The security model is shared; the integration boundary is different.
Cloud / Object API
Eleven authenticated routes coordinate encryption, recovery, re-encryption, raw entropy issuance, provisioning, and diagnostics. Requests exchange JSON, object locations, and key references; payload bytes remain on the customer-controlled storage path rather than being carried inline through the control-plane request.
The customer-deployed service resolves the references inside its runtime and writes ciphertext, K3Y, and authorized Trust/JSON evidence to customer-controlled destinations.
az:// · s3:// · gcs:// for data; kv:// · kvk:// for customer-controlled key material.Interface Contract
| Service endpoint | https://<customer-endpoint>/ | Customer-controlled deployment endpoint inside the selected VNet, cluster, VM, or container environment. |
|---|---|---|
| Authentication | Authorization: Bearer $TOKEN | Bearer authentication is required; JWT may be enabled where the deployment is configured for it. |
| Payload model | Object URIs | Encrypt/decrypt requests reference source and destination objects instead of embedding payload bytes in JSON. |
| Key model | Vault / managed-key references | Requests identify the AES, signing, and optional PQC material required for the operation. |
| Response model | JSON status + Trust / URI metadata | Responses report operation state and authorized metadata while the protected object remains on its storage path. |
Route Index
| Class | Method | Route | Purpose |
|---|---|---|---|
| Job | POST | /v1/job | Submit asynchronous encrypt, decrypt, or reencrypt work. |
| GET | /v1/job/{id} | Read job status through a terminal result. | |
| Crypto | POST | /v1/encrypt | Synchronously protect a referenced object. |
| POST | /v1/decrypt | Synchronously restore a referenced object after validation. | |
| POST | /v1/reencrypt | Rotate K3Y / Trust metadata while preserving the existing ciphertext and Particle seed context. | |
| POST | /v1/entropy | Issue sealed random bytes directly, without an input object to transform. | |
| POST | /v1/keygen | Provision the deployment key/reference set. | |
| POST | /v1/unwrap | Inspect authorized K3Y Trust metadata without restoring payload bytes. | |
| Diagnostics | GET | /v1/health | Read service readiness and configured crypto posture. |
| POST | /v1/test | Run the deployment roundtrip fitness check. | |
| POST | /v1/kat | Run known-answer cryptographic self-checks. |
Job Operations
The job API separates submission from completion. A client submits an encrypt, decrypt, or reencrypt operation, receives a job identifier immediately, and polls the status resource while the byte operation executes inside the customer-controlled boundary.
Payload bytes are referenced by URI; they are not carried inline through the control-plane request.
Job Lifecycle
| Stage | API action | What happens | Client responsibility |
|---|---|---|---|
| ACCEPT | 202 Accepted | The service returns job_id and status_uri immediately. | Persist the returned job identifier. |
| EXECUTE | In-boundary processing | ΞNIGMA reads the referenced object, performs encrypt or decrypt, and writes the result to the requested destination. | No inline payload transfer is required. |
| POLL | GET /v1/job/{id} | The status resource reports the current job state. | Poll until the job reaches succeeded or failed. |
| COMPLETE | Terminal status | Success exposes result/Trust metadata and the K3Y URI; failure exposes error information. | Consume the result or handle the failure. |
/v1/jobSubmit an encrypt, decrypt, or reencrypt job. The request describes where the bytes and key material live and which controls apply; the operation itself runs asynchronously inside the cloud boundary.
Request Contract
| Layer | Field | Req. | Purpose / behavior |
|---|---|---|---|
| JOB | type | Required | "encrypt", "decrypt", or "reencrypt". Determines whether bytes are protected, restored, or re-bound to a rotated Trust/K3Y recovery context. |
source_uri | Required | Object URI read as input — plaintext for encrypt, ciphertext for decrypt, or ciphertext for reencrypt. Example format: az://container/path. | |
destination_uri | Required | Object URI receiving output — ciphertext for encrypt, plaintext for decrypt, or the updated K3Y output path for reencrypt. | |
k3y_uri | Conditional | Separate K3Y location. Encrypt writes the new capsule here; decrypt reads the source capsule from this path; reencrypt uses it as the source K3Y to rotate into a refreshed recovery bundle. | |
id | Optional | Stable payload identifier carried into Trust/job metadata for audit and correlation. | |
codes | Optional | String array committed into the gated cryptographic context. Incorrect values are expected to cause decrypt authentication failure. | |
enforce | Optional | Policy string committed into the gated context and expected to match at decrypt. | |
info | Optional | Audit / provenance metadata carried in Trust; not presented here as a decrypt gate. | |
| FIPS CORE | aes_256_gcm_uri | Required | Key Vault secret URI for the 32-byte AES-256-GCM key used to seal/unseal the K3Y Trust capsule. |
ecdsa_p384_uri | Required for encrypt/reencrypt | Primary ECDSA-P384 signing key reference. kv:// may reference a secret; kvk:// may reference a managed Key Vault key. | |
ecdsa_p384_secondary_uri | Optional | Secondary P-384 key for dual-signature coverage; when configured, both signatures must verify. | |
expected_ecdsa_pk_sha256_hex | Optional | SHA-256 digest of the expected signer public key, checked on decrypt before restored bytes are committed. | |
expected_ecdsa_pk_hex | Optional | Full expected P-384 public key, used as an alternative to the digest form. | |
| PQC ADJUNCT | kyber_768_uri | Optional | ML-KEM-768 key reference: public material for encrypt and private material for decrypt when the PQC adjunct is enabled. |
ml_dsa_uri | Optional | ML-DSA signing / verification key reference for the Trust capsule when configured. | |
slh_dsa | Optional | SLH-DSA signing / verification key reference for the optional hash-based signature layer. |
Accepted Response
{
"job_id": "job-audit-q2",
"status": "accepted",
"status_uri": "/v1/job/job-audit-q2"
}
Submit 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"
}'
/v1/job/{id}Fetch the status record for the job_id returned at submission. Continue polling until the status is "succeeded" or "failed".
| Field / state | Meaning |
|---|---|
id path parameter | The job_id returned by POST /v1/job. |
accepted | The service accepted the asynchronous operation and issued a status resource. |
succeeded | The operation completed. Trust/result metadata and the K3Y location can be returned on the status record. |
failed | The operation terminated without success. Failure information can include error, error_code, and error_label. |
Successful Status Record
{
"job_id": "job-audit-q2",
"status": "succeeded",
"k3y_uri": "az://trust/audit.k3y",
"trust": { "trust_id": "...", "fips": true },
"error": null
}
The job record is the coordination object; the cloud object URIs remain the data path. Submission tells ΞNIGMA where to work, polling tells the client when that work is finished, and K3Y/Trust references remain separate from the ciphertext object.
Synchronous REST Cryptographic Operations
Six synchronous REST endpoints expose the cloud/object workflow without the asynchronous job lifecycle: protect a referenced object, restore a referenced object, rotate Trust/K3Y for the same ciphertext, issue sealed random bytes, provision the deployment key set, or inspect K3Y Trust metadata. These remain URI-based service calls. The native byte/crate surface is documented separately below.
Encrypt, decrypt, and reencrypt operate on referenced objects inside the customer boundary; entropy issues raw sealed bytes with no source object; unwrap inspects the capsule without processing the ciphertext payload.
Operation Matrix
| Operation | Endpoint | Primary input | Primary result |
|---|---|---|---|
| Encrypt | POST /v1/encrypt | Plaintext object + key/policy references | Ciphertext object + separate K3Y + Trust JSON |
| Decrypt | POST /v1/decrypt | Ciphertext object + K3Y + matching controls | Restored plaintext + Trust JSON |
| Reencrypt | POST /v1/reencrypt | Ciphertext object + source K3Y + updated key / Trust references | Updated K3Y bundle and rotated Trust metadata for the same ciphertext |
| Entropy | POST /v1/entropy | Byte count + key/policy references (no source object) | Sealed random bytes, optional object write, K3Y + Trust JSON |
| Keygen | POST /v1/keygen | Vault target + naming policy | Stable URIs for the generated key set |
| Unwrap | POST /v1/unwrap | K3Y + unseal/verification references | Authorized Trust metadata; payload untouched |
/v1/encryptSynchronous direct encrypt. Reads plaintext from source_uri, applies the configured Particle XOR transform and FIPS cryptographic sealing in-boundary, writes ciphertext to destination_uri, writes the K3Y capsule to k3y_uri, and returns Trust JSON inline. The type field is inferred from the path.
Encrypt Request Contract
| Layer | Field | Req. | Purpose |
|---|---|---|---|
| INPUTS | source_uri | Required | Blob URI of the plaintext bytes to encrypt. |
destination_uri | Required | Blob URI that receives the ciphertext bytes. | |
k3y_uri | Conditional | Separate Blob path where encrypt writes the .k3y capsule for later decrypt or unwrap. | |
id | Optional | Stable payload identifier recorded in Trust metadata for audit correlation. | |
codes / enforce / info | Optional | Policy codes, enforcement payload, and audit metadata committed into the seal context. | |
| FIPS CORE | aes_256_gcm_uri | Required | Key Vault URI for the AES-256-GCM key that seals the K3Y Trust capsule. |
ecdsa_p384_uri | Required | Primary P-384 signing key. kv:// may reference a secret; kvk:// may reference a managed Key Vault key. | |
ecdsa_p384_secondary_uri | Optional | Secondary P-384 signing key for dual-signature coverage. | |
| PQC ADJUNCT | kyber_768_uri | Optional | ML-KEM-768 recipient public key URI used when the K3Y is post-quantum wrapped. |
ml_dsa_uri | Optional | ML-DSA signing key URI used to append the configured Trust signature adjunct. | |
slh_dsa | Optional | SLH-DSA signing key URI used to append the configured hash-based signature adjunct. |
Response · 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"
}'
/v1/decryptSynchronous direct decrypt. Reads the K3Y capsule, unseals it with the AES key, verifies the configured policy commitments and signer expectations, then reads ciphertext and writes restored plaintext to destination_uri. Optional PQC adjuncts are verified when they were present during encrypt.
Decrypt Request Contract
| Layer | Field | Req. | Purpose |
|---|---|---|---|
| INPUTS | source_uri | Required | Blob URI of the ciphertext bytes produced by the original encrypt operation. |
destination_uri | Required | Blob URI that receives restored plaintext after verification succeeds. | |
k3y_uri | Required | Blob URI of the K3Y capsule produced during encrypt. | |
codes / enforce / info | Optional | Values supplied for the corresponding committed context at decrypt. | |
| FIPS CORE | aes_256_gcm_uri | Required | Key Vault URI for the AES-256-GCM key used to unseal the K3Y capsule. |
expected_ecdsa_pk_sha256_hex | Optional | SHA-256 digest of the expected signer public key, checked before restored bytes are committed. | |
expected_ecdsa_pk_hex | Optional | Full expected P-384 public key; alternative to the digest form. | |
| PQC ADJUNCT | kyber_768_uri | Optional | ML-KEM-768 private key URI when the incoming K3Y was post-quantum wrapped. |
ml_dsa_uri | Optional | ML-DSA verification key URI when the capsule carries the configured adjunct signature. | |
slh_dsa | Optional | SLH-DSA verification key URI when the capsule carries the configured hash-based adjunct signature. |
No plaintext is committed when a required integrity, commitment, or signature check fails. GMAC chunk verification, K3Y authentication, policy context, and configured signer expectations are part of the restoration gate.
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"
}'
/v1/reencryptRe-encrypts the same ciphertext under a refreshed K3Y/Trust context without rewriting the original payload bytes. The service verifies the existing ciphertext against the source K3Y and then emits a rotated K3Y bundle with updated AES, signer, policy, and optional PQC references. This is a metadata-and-recovery rotation operation, not a second plaintext encrypt pass.
Reencrypt Request Contract
| Layer | Field | Req. | Purpose |
|---|---|---|---|
| INPUTS | source_uri | Required | Blob URI of the ciphertext bytes already protected by the original encrypt operation. Bytes are read but never rewritten by reencrypt. |
destination_uri | Required | Blob URI that receives the refreshed K3Y bundle output. This is a K3Y write target, not a ciphertext copy. | |
k3y_uri | Required | Source capsule URI containing the original K3Y and Trust metadata that must be reopened and rotated. | |
aes_256_gcm_uri | Required | AES-256-GCM key that opens the existing (source) K3Y capsule before rotation. | |
updated_aes_256_gcm_uri | Required | New AES-256-GCM key reference used to seal the refreshed K3Y capsule. | |
| FIPS CORE | ecdsa_p384_uri | Required | New primary ECDSA-P384 signer used to produce the updated Trust signature envelope. |
ecdsa_p384_secondary_uri / updated_ecdsa_p384_secondary_uri | Optional | Secondary signer for the refreshed Trust bundle. updated_ecdsa_p384_secondary_uri overrides when the secondary signer itself is being rotated. | |
expected_ecdsa_pk_sha256_hex / expected_ecdsa_pk_hex | Required (one of) | Expected signer pin used to authenticate the existing Trust/K3Y before the rotate step is accepted. | |
| PQC ADJUNCT | kyber_768_uri / source_kyber_768_uri / updated_kyber_768_uri | Optional | ML-KEM private key to open the source K3Y (kyber_768_uri or the source_* override) and the new public key for the rotated K3Y (updated_kyber_768_uri, falling back to kyber_768_uri). |
ml_dsa_uri / source_ml_dsa_uri / updated_ml_dsa_sk_uri / updated_ml_dsa_pk_uri | Optional | ML-DSA verification key for the source Trust and signing/verification keys for the rotated Trust, when the PQ signature adjunct is configured. | |
slh_dsa / source_slh_dsa / updated_slh_dsa_sk_uri / updated_slh_dsa_pk | Optional | SLH-DSA verification key for the source Trust and signing/verification keys for the rotated Trust, when the hash-based adjunct is configured. | |
| POLICY / AUDIT | codes / enforce / info | Optional | Base policy and audit values. Used for both source verification and the updated Trust unless overridden below. |
source_codes / source_enforce / source_info | Optional | Overrides used only to authenticate the existing source Trust/K3Y, when they differ from the values being written forward. | |
updated_codes / updated_enforce / updated_info / updated_id | Optional | Overrides bound into the newly rotated Trust context; when omitted, the base codes / enforce / info values are reused. |
The source ciphertext and source K3Y are re-validated before the rotate step commits. The operation preserves the original payload semantics while constructing a new Trust/K3Y bundle and updated recovery context under the selected key and policy controls.
Example
curl "$BASE_URL/v1/reencrypt" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"source_uri": "az://data/enc/audit",
"destination_uri": "az://trust/audit-rotated.k3y",
"k3y_uri": "az://trust/audit.k3y",
"aes_256_gcm_uri": "kv://keys/enigma",
"updated_aes_256_gcm_uri": "kv://keys/enigma-rotated",
"ecdsa_p384_uri": "kvk://keys/finance-es384-rotated",
"expected_ecdsa_pk_sha256_hex": "deadbeef...",
"codes": ["7842","11903"],
"enforce": "tenant:contoso policy:v4"
}'
/v1/entropyIssues raw, FIPS-backed random bytes directly, without reading a source object to transform. The requested byte count is generated, optionally written to destination_uri, and always sealed into a K3Y/Trust bundle so the same bytes can be authenticated and accounted for like any other protected artifact.
Entropy Request Contract
| Layer | Field | Req. | Purpose |
|---|---|---|---|
| INPUTS | bytes | Required | Number of random bytes to generate. Bounded by the deployment's configured max chunk size. |
destination_uri | Optional | Blob URI that receives the generated bytes; when omitted, only the sealed K3Y/Trust bundle is produced. | |
k3y_uri | Optional | Blob URI that receives the K3Y capsule sealing the generated bytes' Trust/provenance context. | |
codes / enforce / info | Optional | Policy and audit metadata committed into the sealed Trust context for the issued entropy. | |
| FIPS CORE | aes_256_gcm_uri | Required | AES-256-GCM key reference used to seal the K3Y Trust capsule for the generated bytes. |
ecdsa_p384_uri / ecdsa_p384_secondary_uri | Required / Optional | Primary (required) and optional secondary P-384 signer for the Trust signature envelope. | |
| PQC ADJUNCT | kyber_768_uri | Optional | ML-KEM-768 public key reference used when the K3Y is post-quantum wrapped. |
ml_dsa_uri | Optional | ML-DSA signing key reference for the configured Trust signature adjunct. | |
slh_dsa | Optional | SLH-DSA signing key reference for the configured hash-based signature adjunct. |
Response
{
"bytes": 48,
"trust_id": "trust-entropy-9f2",
"qscc_id": "qscc-9f2",
"trust": { "trust_id": "...", "fips": true },
"k3y_uri": "az://trust/entropy-9f2.k3y",
"destination_uri": "az://data/random/entropy-9f2.bin"
}
Example
curl "$BASE_URL/v1/entropy" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"bytes": 48,
"destination_uri": "az://data/random/entropy-9f2.bin",
"k3y_uri": "az://trust/entropy-9f2.k3y",
"aes_256_gcm_uri": "kv://keys/enigma",
"ecdsa_p384_uri": "kvk://keys/finance-es384"
}'
/v1/keygenGenerates the deployment key set into the named Key Vault and returns stable URIs for later encrypt, decrypt, and unwrap calls. The FIPS core includes AES-256-GCM plus primary and secondary ECDSA-P384 material; optional PQC adjunct keys are generated when that build capability is enabled.
Provisioning Contract
| Group | Field | Req. | Purpose |
|---|---|---|---|
| VAULT | vault | Required | Key Vault name or base URL where generated material is written. |
| NAMING | prefix | Optional | Shared name prefix for generated keys. Default: "il7"; per-environment prefixes isolate key sets. |
key_name | Optional | Override for the AES-256-GCM key name. Default: "{prefix}-aes". | |
ecdsa_secondary_name | Optional | Override for the secondary ECDSA-P384 key name. |
Returned Key Families
| Stack | Returned references |
|---|---|
| FIPS core | aes_256_gcm, ecdsa_p384, ecdsa_p384_secondary |
| PQC adjunct | kyber_768_pub/sk, ml_dsa_pk/sk, slh_dsa_pk/sk |
Example
curl "$BASE_URL/v1/keygen" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{ "vault":"pqc-kv", "prefix":"finance-prod" }'
Response · 200 OK
{
"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"]
}
/v1/unwrapUnseals a K3Y capsule and returns authorized Trust metadata without processing the ciphertext payload. Use it for audit inspection, provenance review, SIEM ingestion, and compliance reporting where plaintext restoration is not required.
Unwrap Request Contract
| Layer | Field | Req. | Purpose |
|---|---|---|---|
| CAPSULE | 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. | |
| CONTEXT | codes / enforce / info | Optional | Values supplied for the corresponding committed context from the original encrypt operation. |
| PQC VERIFY | kyber_768_uri | Optional | ML-KEM-768 private key URI when the K3Y was KEM-wrapped during encrypt. |
ml_dsa_uri | Optional | ML-DSA verification key URI when the capsule contains that adjunct signature. | |
slh_dsa | Optional | SLH-DSA verification key URI when the capsule contains that adjunct signature. | |
| OUTPUT | return | Optional | "trust_json" returns the parsed Trust record as structured JSON; omit for the raw capsule output. |
Unwrap does not restore payload bytes. It validates and exposes authorized Trust metadata from the K3Y artifact while leaving the ciphertext object untouched.
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"
}'
Encrypt, decrypt, keygen, and unwrap are synchronous controls over the same separated architecture. Payload objects stay on the cloud data path, K3Y remains a distinct recovery artifact, and Trust provides the review/audit record returned by the operation.
Diagnostics
Three endpoints cover three different questions: Is the service ready? Can the deployment complete a full in-memory roundtrip? and Do the configured cryptographic primitives pass their known-answer checks?
Keeping the probes separate makes failures easier to localize and review.
Diagnostic Matrix
| Probe | Endpoint | What it validates | Primary output |
|---|---|---|---|
| Health | GET /v1/health | Service readiness, version, FIPS posture, entitlement, provider summary, and configured limits. | Current readiness/status record. |
| Roundtrip test | POST /v1/test | In-memory encrypt → decrypt fitness path plus timing and throughput. | Bytes, wall time, and throughput metrics. |
| KAT | POST /v1/kat | Known-answer checks against the live cryptographic implementation. | Pass/fail state and optional vectors. |
/v1/healthUse the health endpoint as the liveness/readiness probe. It reports whether the service is operational and exposes the configuration facts an operator needs before sending protected work.
| Area | Reported state | Review purpose |
|---|---|---|
| Service | status, version | Confirms the running build and basic service state. |
| FIPS | FIPS posture / provider | Confirms the expected cryptographic provider boundary is active. |
| Entitlement | Provider + ok state | Shows whether protected operations are enabled for the deployment. |
| Limits | Chunk and in-flight controls | Surfaces the effective request/stream operating limits. |
| Crypto | Symmetric, signing, PQC summary | Provides a concise view of the configured cryptographic stack. |
Example Response
{
"status": "ok",
"version": "il7-1.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" }
}
/v1/testBuilds a synthetic payload in memory and runs a complete encrypt → decrypt roundtrip without touching external storage. Use it after provisioning to confirm the deployment path and establish an in-boundary performance baseline.
| Input / metric | Req. | Meaning |
|---|---|---|
health_mb | Optional | Synthetic payload size in MB. An empty body is accepted; larger values increase throughput and memory pressure. |
requested_bytes | Output | Total bytes exercised by the roundtrip. |
enc_wall_s | Output | Measured encryption wall time. |
dec_wall_s | Output | Measured decryption wall time. |
roundtrip_s | Output | Total measured roundtrip duration. |
tput_gib_s | Output | Reported in-boundary throughput for the synthetic test. |
Request
curl "$BASE_URL/v1/test" \
-H "Authorization: Bearer $TOKEN" \
-d '{ "health_mb":64 }'Response
{
"requested_bytes": 1048576,
"tput_gib_s": 3.421,
"enc_wall_s": 0.141,
"dec_wall_s": 0.148,
"roundtrip_s": 0.289
}/v1/katRuns the known-answer-test suite against the live cryptographic implementation. A full pass returns 200; a vector failure returns an error state suitable for compliance and release-review workflows.
| Option | Req. | Behavior |
|---|---|---|
emit | Optional | When true, emits test vectors for export / external tooling rather than the normal executed-check view. |
compact | Optional | When true, omits full hexadecimal vectors and returns a concise result summary. |
Coverage
| Layer | Covered algorithms / constructions |
|---|---|
| Derivation + MAC | HKDF-SHA-384 · HMAC-SHA-256 · GMAC-256 |
| Authenticated seal | AES-256-GCM |
| Classical signing | ECDSA-P384 / SHA-384 |
| Bound context | AAD_v1 · Trust ID_v1 construction |
| PQC adjunct | Kyber-768 / ML-KEM · ML-DSA · SLH-DSA when enabled |
Compact Run
curl "$BASE_URL/v1/kat" \
-H "Authorization: Bearer $TOKEN" \
-d '{ "compact":true }'
A green health probe does not replace a roundtrip or a KAT. Health answers whether the service is ready; /v1/test exercises the deployed data path in memory; /v1/kat checks cryptographic vectors. Run the layer that matches the question being investigated.
ΞNIGMA 3.0 Binary Interface
Restricted local commands expose encrypt, decrypt, Trust inspection, and test-key generation without cloud staging. Payload data streams through stdin and stdout; key material is supplied explicitly to the process.
Use requires approved access / use-case controls. Binary flags use explicit hexadecimal key material rather than cloud key URIs.
Command Matrix
| Command | Input | Output | Primary purpose |
|---|---|---|---|
encrypt | Plaintext on stdin | Raw ciphertext or bundled K3Y + ciphertext | Protect a local stream using the configured FIPS core and optional PQC adjuncts. |
decrypt | Bundle or raw ciphertext on stdin | Verified plaintext on stdout | Restore bytes after K3Y, gate, and signer verification succeed. |
trust | K3Y on stdin | Redacted Trust JSON | Inspect authorized Trust metadata without processing payload bytes. |
keygen | Selector + required environment | Local test key files | Generate AES, P-384, ML-KEM/Kyber, ML-DSA, and SLH-DSA test material. |
[4-byte big-endian K3Y length] [K3Y capsule] [ciphertext]
Bundled decrypt reads the embedded K3Y directly; raw-ciphertext decrypt requires the K3Y to be supplied separately.
Flag Contract by Command
| Command | Required / primary controls | Optional / conditional controls | Notes |
|---|---|---|---|
encrypt |
--aes-hex--ecdsa-sk-hex |
--ecdsa-secondary-sk-hex--kyber-pub-hex--ml-dsa-sk-hex / --ml-dsa-pk-hex--slh-dsa-sk-hex / --slh-dsa-pk-hex--id · repeatable --code · --info-hex · --enforce-hex · --bundle |
--bundle emits K3Y and ciphertext as one framed stream. |
decrypt |
--aes-hexone expected signer pin |
--k3y-hex for raw ciphertext--expect-ecdsa-pk-hex or --expect-ecdsa-pk-sha256-hex--kyber-sk-hex · --ml-dsa-pk-hex · --slh-dsa-pk-hexrepeatable --code · --info-hex · --enforce-hex |
Bundle input embeds K3Y, so --k3y-hex is omitted. |
trust |
--aes-hex |
--kyber-sk-hex · --ml-dsa-pk-hex · --slh-dsa-pk-hex--code · --info-hex · --enforce-hex |
Returns redacted Trust JSON; payload bytes are not restored. |
keygen |
all | fips | pqcIL7_ALLOW_GENKEYS=1AWS_LC_RUST_FIPS=1 |
--features both / combined test stack where required |
Writes the configured local test key set under data/keys/. |
Local Roundtrip
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"The binary changes the transport surface, not the cryptographic responsibilities. Local streams replace cloud object URIs, but K3Y separation, gate validation, signer verification, and the FIPS/PQC role split remain the same review concerns.
Every critical path is tested for success, failure, and recovery.
ΞNIGMA’s internal validation system continuously exercises the same cryptographic behaviors the platform depends on in production: FIPS readiness, complete key material, Particle encrypt/decrypt correctness, K3Y and Trust recovery, policy-gate enforcement, re-encryption, metering, diagnostics, and release-state integrity. The goal is not simply to prove that the happy path works; it is to prove that invalid state is rejected, recovered bytes are correct, evidence is emitted, and each supported release configuration behaves as expected.
Each validation path has an expected outcome: valid state must complete, invalid state must fail closed, protected artifacts must remain internally consistent, and recovered plaintext must match the original data. Tests also preserve reviewable evidence—status, Trust, timing, metering, K3Y, ciphertext, and restored-output artifacts—so failures can be investigated instead of reduced to a single pass/fail flag.
| Assurance domain | Automated invariant | Required result |
|---|---|---|
| RELEASE READINESS | FIPS-only and FIPS + PQC profiles build and execute successfully. | No profile inherits confidence from another build; each supported release posture must stand on its own. |
| KEY READINESS | AES, primary/secondary P-384, ML-KEM/Kyber, ML-DSA, and SLH-DSA material is complete before full-stack validation proceeds. | Partial key state is treated as not ready. |
| ROUNDTRIP CORRECTNESS | Encrypt → decrypt returns the expected byte count and original content. | Length and independent SHA-256 checks must agree with the source. |
| FAIL-CLOSED POLICY | Wrong, incomplete, or absent gated material is deliberately exercised. | Decrypt must reject invalid codes or enforce state. |
| TRUST + K3Y | K3Y recovery, signer expectations, policy bindings, and redacted Trust output are validated. | Authorized Trust is recoverable; incomplete or mismatched recovery state is rejected. |
| STATE TRANSITION | Re-encryption rotates protected state and then decrypts under only the updated state. | Updated K3Y must recover the original plaintext; source-state assumptions must not silently carry forward. |
| USAGE EVIDENCE | Encrypt/decrypt meter events carry bytes, timing, throughput, identifiers, digests, and idempotency material. | Metering remains reviewable without changing the underlying cryptographic path. |
| DIAGNOSTICS | Health, runtime test, and known-answer-test reporting are exercised as part of readiness validation. | Provider, algorithm, and deployment-health failures surface before production use. |
What is continuously exercised
| Validation area | What the internal test does | What it proves |
|---|---|---|
| Release build matrix | Builds and runs the supported FIPS-only and combined FIPS + PQC configurations with the FIPS provider enabled. | Feature combinations are validated independently and cannot silently rely on another profile’s success. |
| Health + provider readiness | Executes the production health path and captures version, FIPS provider state, algorithm availability, entitlement state, and configured limits. | The running release reports the expected cryptographic posture before data operations begin. |
| Complete key generation | Generates and validates AES, primary + secondary ECDSA-P384, ML-KEM/Kyber, ML-DSA, and SLH-DSA material. | No full-stack test proceeds with empty or incomplete cryptographic material. |
| Encrypt/decrypt roundtrip | Encrypts a real sample, emits ciphertext and K3Y, decrypts with signer expectations and policy state, and records phase timing. | Written byte counts match the source and the complete recovery path functions end to end. |
| Independent plaintext verification | Compares the source and restored output with an external SHA-256 calculation. | Roundtrip correctness is checked outside the cryptographic process itself rather than trusted from an internal success return. |
| K3Y + Trust inspection | Recovers K3Y from the supported artifact forms, unwraps authorized Trust, validates required crypto material, and persists a redacted Trust view. | Recovery metadata remains separable from payload bytes and requires the expected cryptographic/policy context. |
| Wrong-code rejection | Attempts decrypt with an incorrect code and, where multiple codes are required, with incomplete subsets before the complete expected set is supplied. | Codes behave as an ordered, required gate rather than advisory metadata. |
| Wrong or missing enforce rejection | Attempts decrypt with mismatched enforce data and with enforce omitted, then repeats with the correct authenticated value. | Enforce is bound into authentication and invalid policy context fails closed. |
| Info non-gating behavior | Exercises encrypt/decrypt while allowing informational metadata to differ where the design permits it. | Audit/analytics metadata is not accidentally promoted into a recovery gate. |
| Re-encryption + policy rotation | Encrypts under source AES/codes/info/enforce, creates updated protection state, then decrypts using the updated AES and policy context. | The transition source state → updated K3Y → restored plaintext is complete and deterministic. |
| Metering integrity | Captures canonical encrypt/decrypt usage events with bytes, wall time, throughput, Trust/QSCC digests, payload/call identifiers, marketplace fields, and an idempotency key. | Commercial/usage telemetry can be reviewed independently without introducing a separate test-only crypto implementation. |
| Known-answer and runtime diagnostics | Runs algorithm self-checks and deployment-level test operations alongside health reporting. | Cryptographic primitives and the deployed execution path are checked before customer workloads depend on them. |
| Artifact and log evidence | Persists status JSON, redacted Trust, K3Y, ciphertext, restored output, timing, and metering artifacts with stable and run-specific identifiers. | Regression review has concrete evidence rather than only console output. |
| Error-path handling | Deliberately exercises missing samples, invalid lengths, failed child operations, incomplete key state, mismatched policy, and other invalid inputs. | Failure conditions terminate the validation path instead of being downgraded to warnings. |
Patterns enforced across the internal test system
| # | Pattern | Why it matters |
|---|---|---|
| 01 | Positive and negative paths are paired | A successful decrypt is never treated as sufficient evidence by itself; the same gate is challenged with wrong and missing state to prove rejection behavior. |
| 02 | Every supported crypto profile is exercised | FIPS-only and FIPS + PQC builds are validated independently so feature combinations cannot hide configuration regressions. |
| 03 | Independent data verification | Recovered content is checked by length and external SHA-256, creating a second correctness oracle outside the core operation. |
| 04 | Artifacts are first-class evidence | Status, Trust, K3Y, ciphertext, restored output, timing, and usage records are retained in reviewable forms for regression and audit work. |
| 05 | State transitions are tested end to end | Re-encryption must end with successful recovery under the updated state; metadata rotation alone does not count as success. |
| 06 | Complete cryptographic state is required | Missing or empty key families fail readiness instead of allowing a partially configured stack to appear healthy. |
| 07 | Policy semantics are tested explicitly | codes and enforce are proven as gates while info is proven as non-gating metadata, preventing accidental semantic drift. |
| 08 | Production behavior is reused | Roundtrip, Trust, re-encryption, diagnostics, and metering validation exercise the same operational primitives rather than duplicate cryptographic logic for tests. |
| 09 | Metering is observable but non-invasive | Usage evidence is captured around canonical operations, so commercial telemetry can be validated without becoming part of the encryption algorithm. |
| 10 | Timing is decomposed | Read, cryptographic, write, Trust, and total wall-time measurements make regressions attributable instead of collapsing all latency into one number. |
| 11 | Output paths and artifacts are constrained | Generated test artifacts are normalized and bounded so validation itself does not introduce unsafe path behavior. |
| 12 | Failure is evidence | Expected rejection is captured deliberately and counted as a passing security property only when the invalid operation actually fails. |
Invalid recovery state is rejected. Complete recovery state is verified before release.
A successful decrypt proves only the positive path. Internal assurance also challenges each required gate with incorrect, incomplete, and missing state. Recovery succeeds only when the expected gated context is present and valid.
| Recovery condition | Expected behavior | Security property demonstrated |
|---|---|---|
| Wrong code | Reject | Unauthorized recovery context is denied. |
| Partial code set | Reject | A required multi-part gate cannot be weakened by omission. |
Wrong enforce | Reject | A policy or environment mismatch fails authentication. |
Missing enforce | Reject | Required AAD-bound policy cannot be bypassed by leaving it out. |
| Complete expected state | Decrypt + verify | Authorized recovery restores the expected bytes and Trust context only after validation succeeds. |
| Evidence | Review use |
|---|---|
| Status + health JSON | Confirms release profile, provider readiness, command outcome, and diagnostic state. |
| Redacted Trust JSON | Confirms Trust identity, cryptographic stack flags, policy commitments, provenance, and runtime telemetry without exposing plaintext. |
| K3Y artifacts | Preserves the exact recovery capsule used for unwrap, decrypt, and re-encryption validation. |
| Ciphertext + restored output | Supports independent roundtrip and regression comparison. |
| SHA-256 comparison | Provides an external integrity oracle for original vs. restored bytes. |
| Timing + throughput | Separates I/O, cryptographic work, Trust handling, and total execution for performance regression review. |
| Metering events | Confirms usage identifiers, bytes, throughput, digests, marketplace metadata, and idempotency behavior. |
Embed ΞNIGMA below the storage layer.
The supplied Rust harness exercises the same core without REST or object storage. A caller constructs EncryptOptions / DecryptOptions, supplies AES, ECDSA and optional PQC material, then passes ordinary Rust Read and Write implementations into core::encrypt and core::decrypt. That means the source can be a file, memory buffer, socket, pipe, database stream, device stream, or any other reader/writer the host application controls.
Only the integration boundary changes: cloud mode resolves URIs; native mode receives the actual byte streams and key bytes from the caller.
Read plaintext / ciphertextFile, buffer, pipe, socket or application-owned stream.codes, info, enforce.core::encrypt/decryptParticle byte transform plus Trust/K3Y protection and validation.Write bytes + K3YCiphertext/plaintext is streamed; K3Y/Trust is returned separately.Cloud API vs. native byte API
| Integration concern | Cloud / object REST surface | Native Rust / byte surface |
|---|---|---|
| I/O | source_uri, destination_uri, k3y_uri | Read + Write implementations supplied by the application |
| Object addressing | az://, s3://, gcs:// | None required; caller already has the bytes |
| Key addressing | kv://, kvk://, Vault/KMS/HSM references | Key bytes/signers supplied directly to the core by the host application |
| Execution | Customer-deployed service reads and writes referenced objects | Host process executes core::encrypt, core::decrypt, core::reencrypt |
| Policy | JSON fields: codes, enforce, info | EncryptOptions / DecryptOptions carry the same contexts |
| Recovery | K3Y stored at the requested customer URI | K3Y returned as bytes; host decides where/how to custody it |
| Evidence | REST/job responses + Trust JSON → SIEM | Redacted Trust returned/logged by harness; host can export the same record |
Rust crate — encrypt bytes
use il7::il7 as core;
use il7::trust::LocalEcdsaSigner;
let signer = LocalEcdsaSigner::from_pkcs8(&ecdsa_sk)?;
let opts = core::EncryptOptions::new(
Some(ecdsa_secondary_sk.as_slice()),
Some(kyber_pub.as_slice()),
Some(slh_sk.as_slice()),
Some(slh_pk.as_slice()),
Some(id),
Some(&codes),
Some(info_bytes),
Some(enforce_bytes),
).with_ml_dsa(
Some(ml_dsa_sk.as_slice()),
Some(ml_dsa_pk.as_slice()),
);
let (k3y, trust_json, written) = core::encrypt(
reader, // any Read
writer, // any Write
&aes,
&signer,
opts,
Some(max_chunk),
)?;
Rust crate — decrypt bytes
let opts = core::DecryptOptions::new(
Some(kyber_sk.as_slice()),
Some(slh_pk.as_slice()),
Some(&codes),
Some(info_bytes),
Some(enforce_bytes),
None,
)
.with_ml_dsa(Some(ml_dsa_pk.as_slice()))
.with_expected_ecdsa(Some(ecdsa_pk.as_slice()), None);
let (trust_json, written) = core::decrypt(
cipher_reader, // any Read
plain_writer, // any Write
cipher_len,
&k3y,
&aes,
opts,
Some(max_chunk),
)?;
Rust harness dispatcher
The test crate is intentionally a thin command dispatcher over focused harness modules. That keeps the developer proof close to the same public core calls an embedded integration uses.
| Harness command | Rust module | What it exercises |
|---|---|---|
basic / roundtrip | roundtrip.rs | Direct crate encrypt → K3Y/Trust → direct crate decrypt, byte counts, timing, Trust logs, restored output. |
trust / unwrap | unwrap.rs | Authorized K3Y unwrap through unwrap_bind_info, redacted Trust JSON, trust_id-keyed logs, no plaintext restoration. |
keys | keys.rs | Calls keygen_material(), requires the combined feature set, verifies PQC material is non-empty, writes AES/ECDSA/ML-KEM/ML-DSA/SLH-DSA files. |
health | health.rs | Builds the release binary with FIPS enabled, runs il7 health, and persists the JSON health record. |
test [matrix|fips|both] | test.rs | Builds and runs FIPS-only and/or combined FIPS+PQC variants, executing health and test and writing status JSON for each variant. |
reencrypt | reencrypt.rs | Encrypts once, rotates AES/Trust/policy context around the existing ciphertext, then decrypts with the updated K3Y and verifies plaintext equality. |
data/samples → data/otp / ciphertext → data/k3ys → data/plain → data/logs/trust|status|health.Direct harness — call the crate
# Generate local FIPS + PQC test keys AWS_LC_RUST_FIPS=1 cargo run --release \ --manifest-path test/crate/Cargo.toml \ --features both -- keys il7 # Full crate-level encrypt → decrypt roundtrip AWS_LC_RUST_FIPS=1 cargo run --release \ --manifest-path test/crate/Cargo.toml \ --features both -- roundtrip christmas.pdf il7 # Unwrap K3Y / Trust without restoring plaintext AWS_LC_RUST_FIPS=1 cargo run --release \ --manifest-path test/crate/Cargo.toml \ --features both -- unwrap christmas.pdf il7 # Re-bind/rotate recovery context and verify decrypt AWS_LC_RUST_FIPS=1 cargo run --release \ --manifest-path test/crate/Cargo.toml \ --features both -- reencrypt christmas.pdf il7
Readiness / FIPS + PQC matrix
# Harness health wrapper AWS_LC_RUST_FIPS=1 cargo run --release \ --manifest-path test/crate/Cargo.toml \ --features both -- health # Build/run FIPS-only + combined FIPS/PQC variants AWS_LC_RUST_FIPS=1 cargo run --release \ --manifest-path test/crate/Cargo.toml \ -- test matrix # Shell readiness path used by the repo bash test/sh/readready.sh
Shell tests — byte-level CLI proof
The shell layer exercises the release binary through stdin/stdout byte streams. It is useful as an integration proof because the scripts show exactly what a non-Rust process would need to supply: key material, policy context, payload bytes, K3Y custody, and pass/fail expectations.
The shell tests do not upload a blob to a REST endpoint. They literally pipe file bytes into il7 encrypt/decrypt and redirect stdout to ciphertext/plaintext files. That makes them a concrete example for agents, sidecars, local services, appliances, or any process that wants ΞNIGMA below the object-storage layer.
readready.sh
Cleans and builds the release binary with the combined feature set, runs health, creates the complete local FIPS + PQC test key set when needed, runs the test endpoint, and persists JSON status output.
bash test/sh/readready.sh
readrun.sh
Pipes the source file into il7 encrypt, produces a bundle containing K3Y + ciphertext, extracts K3Y, decrypts the byte stream, compares SHA-256, then opens the K3Y through the Trust command.
bash test/sh/readrun.sh data/samples/christmas.pdf \
--codes 7897,34329 \
--info-enc-json '[{"region":"us-west"}]' \
--info-dec-json '[{"region":"us-east"}]' \
--enforce-json '["us-west-188afd","200::204"]'
readcodes.sh
Encrypts with the required ordered code set, proves that a wrong code is rejected, proves incomplete code context is rejected when multiple codes are required, then proves the complete correct set restores the exact original bytes.
bash test/sh/readcodes.sh data/samples/christmas.pdf \ --codes 7897,34329 \ --wrong-code 9999
readenforce.sh
Encrypts with the committed enforce context, then intentionally tries a wrong enforce value and no enforce value. Both must fail. Only the correct enforce context may authenticate and restore plaintext.
bash test/sh/readenforce.sh data/samples/christmas.pdf \ --enforce-json '["us-west-188afd","200::204"]' \ --wrong-enforce-json '["us-east-999999","300::304"]'
readreencrypt.sh
Creates ciphertext and K3Y as independent artifacts, rotates the recovery context to updated AES/policy/codes/info/PQC material, then decrypts the same ciphertext with the updated K3Y stack and verifies the original bytes.
bash test/sh/readreencrypt.sh data/samples/christmas.pdf \ --source-codes 7897,34329 \ --updated-codes 7897,34329,9090
unwrap.rs / trust
Loads the K3Y and required key/policy context, calls core::unwrap_bind_info, emits a redacted Trust view, and saves JSON logs keyed by trust_id. No plaintext restore is required to inspect the authorized record.
AWS_LC_RUST_FIPS=1 cargo run --release \ --manifest-path test/crate/Cargo.toml \ --features both -- unwrap christmas.pdf il7
Use URI-based REST when ΞNIGMA should own object movement inside the customer cloud boundary. Use the Rust crate or byte-stream CLI when the host application already owns the bytes. In both cases the buyer gets the same Particle transform, K3Y separation, codes/enforce/info semantics, Trust evidence, FIPS-backed classical controls and configured PQC adjunct.
Threat Model Summary
This threat model defines what ΞNIGMA is designed to protect, what an attacker may control, which checks are enforced before plaintext or Trust data is released, and which risks remain deployment responsibilities. The emphasis is failure-closed recovery: incorrect cryptographic material, incorrect policy gates, failed integrity checks, or failed signature checks must stop recovery rather than degrade into a weaker path.
valid URI + keys + policyOnly an authorized job with valid object references, key material, and policy inputs can proceed.gates · signatures · MACWrong identities, invalid signatures, bad MACs, or wrong policy stops the path before plaintext is exposed.recover state + re-derive padRecovery is allowed only when the K3Y, Trust record, and configured controls all line up.restore bytes / fail closedSuccessful recovery exits with plaintext; any mismatch exits with a cryptographic rejection rather than a weaker fallback.1. Protected assets and trust boundaries
| Asset / boundary | Security objective | Primary control | Failure consequence |
|---|---|---|---|
| Plaintext object | Confidentiality during read, transform, and restore. | In-boundary processing; plaintext is not a control-plane payload. | A compromised runtime or storage authorization can expose data before or after cryptographic protection. |
| Ciphertext object | Integrity and correct object-to-Trust binding. | Per-chunk integrity evidence committed through Trust plus authenticated recovery checks. | Modified or mismatched bytes must not be accepted as valid plaintext. |
| Particle seed / K3Y | Keep operation-specific recovery material separate from ciphertext. | Fresh seed per encrypt; seed sealed into K3Y; optional ML-KEM protection when the PQC adjunct is enabled. | Loss of the corresponding recovery path prevents legitimate decrypt; compromise of the required recovery keys can expose the seed. |
| Vault / KMS keys | Prevent unauthorized seal, unwrap, and signing operations. | Customer-controlled vault references, IAM, key permissions, and expected signer checks. | Credential or key compromise can defeat cryptographic authorization even when ciphertext itself remains intact. |
| Trust + policy gates | Bind recovery to the intended operation and required policy values. | trust_id, signatures, integrity commitments, codes, and enforce authentication binding. | Incorrect context must fail closed; replay freshness still requires deployment policy. |
2. Adversary model
| Adversary | Assumed capability | What the design attempts to deny |
|---|---|---|
| Passive storage attacker | Copies ciphertext, and possibly a separately stored K3Y artifact, for later analysis. | Plaintext recovery without the required K3Y/key/policy path. |
| Active object attacker | Flips bits, truncates, replaces, reorders, or substitutes stored ciphertext. | Returning modified bytes as authenticated plaintext. |
| Policy-bypass attacker | Presents wrong or missing codes / enforce values. | Recovery under a different tenant, policy, or access context. |
| Identity / signer attacker | Attempts to substitute signing material or present an artifact under the wrong expected signer. | Trust acceptance when signature verification does not match the configured identity. |
| Replay attacker | Reuses a previously valid K3Y or Trust artifact in a later request. | Silent reuse across operations; freshness rejection is a deployment-policy function. |
| Future quantum attacker | Stores protected artifacts now and later gains cryptanalytic capability against classical public-key algorithms. | Long-term compromise of the K3Y/signature path when configured with the PQC adjunct. |
| Privileged environment attacker | Obtains customer IAM, vault credentials, or code execution inside the active runtime. | Not fully denied by cryptography. This is a residual platform-security risk requiring customer controls. |
3. Threat-to-control matrix
| Threat | Control path | Fail-closed condition / evidence | Residual risk |
|---|---|---|---|
| Particle-stream / recovery-state reuse | Fresh independently sampled Particle recovery state for each new encryption; new Trust identity per operation. | The new-encrypt path does not intentionally carry forward an existing Particle context. Metadata-only re-encryption is separately defined and may preserve the original Particle state because ciphertext is unchanged. | Depends on correct entropy generation, collision-resistant freshness in practice, replay discipline, and implementation integrity. |
| Ciphertext tampering | Per-chunk GMAC/integrity evidence plus authenticated Trust commitments. | Integrity or authentication mismatch prevents successful recovery. | Availability attacks remain possible: an attacker can still corrupt or delete data to make it unavailable. |
| Wrong access codes | codes commitments participate in the authenticated recovery context. | Wrong code set is expected to return a non-zero decrypt failure; correct values restore the original object. | Security of the codes themselves depends on how the customer distributes and protects them. |
| Wrong / absent enforce policy | enforce is bound into the AES-GCM authenticated context. | Wrong or missing enforce data is expected to fail authentication; correct enforce succeeds. | Policy quality is a customer responsibility; a weak but syntactically correct policy is still weak. |
| Artifact / signer substitution | Expected ECDSA identity and optional PQ signature verification before Trust release. | Signer or signature verification failure stops decrypt/unwrap. | If PQ signatures are disabled, ECDSA remains the classical authentication dependency. |
| Harvest-now / decrypt-later | Separated ciphertext/K3Y artifacts; ML-KEM-768 protects the K3Y path when the PQC adjunct is enabled. | Possession of ciphertext alone is insufficient; the recovery path still requires the corresponding protected K3Y/key context. | PQC protection is conditional on configuration. Classical vault/session-key compromise remains relevant. |
| Quantum signature forgery | ML-DSA and/or SLH-DSA adjuncts can add independent post-quantum authentication alongside ECDSA-P384. | Configured verification layers must pass before Trust is accepted. | Without the PQ signature adjunct, future quantum risk remains concentrated in classical signatures. |
| Replay / stale Trust | Unique Trust identity and timestamp provide the material needed for freshness policy. | Deployment can reject reused Trust IDs or artifacts outside an allowed freshness window. | Not inherently solved by uniqueness alone. Replay rejection must be enabled/enforced by the deployment policy. |
4. Failure semantics that are exercised automatically
| Security property | Negative case | Expected result | Positive evidence |
|---|---|---|---|
| Code gate | Decrypt with a wrong code. | REJECT non-zero decrypt result. | Correct codes decrypt successfully and the restored file is SHA-256 compared with the source. |
| Enforce gate | Decrypt with wrong enforce data or with enforce omitted. | REJECT authenticated context mismatch. | Correct enforce decrypts successfully and the restored file is SHA-256 compared with the source. |
| Signer / PQ stack | Present an artifact under a verification context that does not satisfy the configured signature stack. | REJECT Trust/decrypt verification does not complete. | The harness verifies the expected ECDSA public key and, when configured, ML-DSA / SLH-DSA public keys. |
| Roundtrip correctness | Unexpected decrypted length or invalid recovery path. | REJECT harness returns an error. | Encrypt/decrypt harness records Trust IDs, byte counts, timings, and completed roundtrip status. |
| K3Y rotation / re-encryption | Attempt to use stale source context after policy/key rotation. | Old and updated recovery contexts are treated as distinct inputs. | The re-encryption harness rotates AES/codes/info/enforce, decrypts with the updated K3Y, and byte-compares restored plaintext to the source. |
5. Residual risks and deployment responsibilities
| Residual risk | Why cryptography alone does not remove it | Required operating control |
|---|---|---|
| Customer IAM / vault compromise | An attacker authorized to use the required keys may be able to perform legitimate-looking cryptographic operations. | Least privilege, managed identity, HSM-backed keys where appropriate, rotation, approval boundaries, and audit review. |
| Runtime / host compromise | Plaintext and seed material necessarily exist transiently while an authorized operation executes. | Hardened images, patching, container isolation, workload identity, memory hygiene, restricted debugging, and host monitoring. |
| Replay freshness | A unique ID proves identity, not freshness by itself. | Persist accepted Trust IDs when required and enforce replay/freshness windows at the deployment boundary. |
| Denial of service / deletion | Authentication can reject corrupted data but cannot make deleted or unavailable storage reappear. | Object versioning, immutability/retention where appropriate, backup, rate limiting, quotas, and availability architecture. |
| PQC configuration drift | The PQC algorithms are adjuncts; disabling them changes the long-term threat posture. | Configuration policy, release checks, health/KAT review, and explicit environment baselines. |
| Custom Particle stream generator | Particle is the ΞNIGMA application construction that creates a full-length operation-specific XOR stream on demand and recreates the same stream only for authorized recovery. Confidentiality is computational and depends on recovery-state secrecy, origin freshness, exact replay, and avoiding intentional cross-operation stream reuse. | Independent cryptographic review, continuous entropy/statistical/implementation testing, and preservation of the authenticated Trust/K3Y, FIPS, and PQC boundaries. |
ΞNIGMA's strongest security property is separation with explicit failure conditions. Ciphertext, K3Y recovery material, customer keys, policy gates, and Trust evidence are distinct controls. The implementation can reject incorrect codes, incorrect enforce data, invalid verification context, and failed recovery paths; the deployment must still protect IAM/KMS credentials, the active runtime, availability, and replay policy. That distinction should remain explicit in production security documentation.
Start with 100 TB for $100,000. Scale by agreement.
Production entry offer: $100,000 for 100 TB of cumulative encrypted input ($1/GB). Customer-owned decryption, normal Trust/K3Y recovery and cryptographic provenance are included. Agree the workload, deployment assistance, support allowance and usage term in writing before activation.
Petabyte expansion: request committed-volume pricing for 1 PB and above. The written agreement specifies the rate, commitment, overage treatment and any entry-package upgrade credit. No automatic petabyte rate or unlimited support is implied.
Outside a written offer, ΞNIGMA’s public list rate is $3/GB encrypted. Customer-owned decryption, normal Trust/K3Y recovery, and cryptographic provenance are included in the public model.
1 PB/year = 1,000,000 GB/year. At $3/GB, the annual ΞNIGMA encryption charge is $3,000,000. The full comparison below now uses the same 1 PB completed workload on both sides.
Reference-model boundary: all $3.010M versus $11.310M TCO figures elsewhere on this page use the $3/GB public list-price scenario. They are illustrative assumptions, not a customer quote or a measured vendor comparison. Entry-offer and petabyte-contract economics require a separate calculation.
Commercial terms at a glance
Volume uses decimal units: 100 TB = 100,000 GB; 1 PB = 1,000,000 GB. Fees measure encrypted input, not stored capacity per month. Billing treatment for failed jobs, retries and recovery-capsule rotation is specified in the written agreement.
| Term | Current position | What it means |
|---|---|---|
| Meter | Encrypted data volume | Usage fees are based on bytes encrypted, not decrypt calls or Trust reads. |
| Public list price | $3/GB | Public list-price reference; the 100 TB entry offer and written volume agreements are separate. |
| Decrypt | Included | Customer-owned decryption does not introduce a second per-GB charge. |
| Trust / K3Y | Included | Normal recovery artifacts, policy evidence, and provenance are part of the operating model. |
| Entitlement | Required | Protected operations remain disabled unless an active entitlement is present. |
| Private pricing | Written agreement only | No private discount is assumed in this public TCO example. |
Public list-price examples — before the entry offer
| Annual encrypted volume | GB billed | Rate | Annual encryption charge |
|---|---|---|---|
| 10 TB | 10,000 GB | $3/GB | $30,000 |
| 100 TB | 100,000 GB | $3/GB | $300,000 |
| 1 PB | 1,000,000 GB | $3/GB | $3,000,000 |
1 PB = 1,000,000 GB → 1,000,000 GB × $3/GB = $3,000,000/year. This comparison retains the public list-price baseline; it does not use the entry offer or negotiated petabyte rates.
License scope
| Category | Commercial treatment |
|---|---|
| Permitted encryption workloads | Bulk files, objects, logs, telemetry, analytics outputs, backups, archives, machine-generated datasets, cloud data pipelines, and long-term customer data protection. |
| Audit outputs | Trust metadata and provenance bound to encrypted outputs are within normal licensed operation. |
| Separate authorization required | Payments, banking, escrow, cryptocurrency/blockchain systems, identity/SSO, secure messaging, VPN or consumer privacy products, randomness/key-custody services, surveillance/interception, and similar out-of-scope uses require explicit written authorization. |
| Redistribution + resale | Redistribution, sublicensing, resale, competing-service use, or embedding the software in a third-party product for resale is prohibited unless separately authorized. |
| Metering controls | Licensing and usage-metering mechanisms must remain intact and operational. |
Procurement + legal review
| Topic | Review position |
|---|---|
| License structure | ΞNIGMA 3.0 is licensed, not sold. Use is subject to the commercial license and applicable written agreements. |
| Billing + reporting | License fees are based on actual encrypted volume. Billing cadence, invoicing, credits, and other commercial mechanics are governed by separate written agreements where applicable. |
| Optional QSCC participation | Any QSCC participation, reporting, certification, or value-sharing requires a separate written agreement and is outside the core encryption license. |
| Warranty posture | The source commercial license states that the software is provided “as is,” without express or implied warranty. |
| Liability posture | The source commercial license includes a limitation-of-liability provision for claims arising from use of the software. |
1 PB. Same workload. Half a day instead of a month.
ΞNIGMA is modeled here as a 3 × 8-vCPU Azure Cobalt 100 cluster. Each 8-vCPU worker measured 6.76 GiB/s encrypt; three independent workers therefore project to 20.28 GiB/s aggregate when the workload scales linearly across jobs or disjoint byte ranges. The illustrative comparison byte path remains 384 MB/s. On the same 1 PB workload, that changes the operating window from roughly a month to about half a day of raw cryptographic work. The cost model below keeps the comparison simple: one 1 PB completed workload on each side, with the slower path allowed to take its modeled ~30.1-day window. Unlike the prior draft, the comparison stack is not frozen at its 300 TB cost base: volume/capacity-sensitive software, PQ, and KMS/HSM allowances scale 3.33× to 1 PB, while fixed program staffing and the single-lane infrastructure allowance remain fixed. A short capacity note separately shows what it would take to match ΞNIGMA throughput, but that scenario is not folded into the main TCO table.
What does it take to actually finish the same protected petabyte?
The advantage is not a theoretical appliance peak. It is the time, cost, and operating burden required to complete the same 1 PB cryptographic objective. In the current model, ΞNIGMA turns a month-scale event into a same-day operation.
Measured vs. modeled is kept explicit. The 6.76 GiB/s figure is the measured 8-vCPU Cobalt result documented above. The 20.28 GiB/s cluster number is a linear three-worker projection, not a separate cluster benchmark. The 384 MB/s comparison rate is a generous planning assumption for a slower per-byte PQ/file-encryption path; a public ML-KEM-based file-encryption implementation reports roughly 187 MB/s on an Apple M1, so 384 MB/s intentionally gives the comparison stack substantial benefit of the doubt.
1 PB completion model
| Measure | ΞNIGMA · 3 × 8 vCPU | Illustrative PQ byte stack | Advantage |
|---|---|---|---|
| Completed encrypted workload | 1 PB / 1,000,000 GB | 1 PB / 1,000,000 GB | Same protected petabyte |
| Per-worker encrypt rate | 6.76 GiB/s measured at 8 vCPU | 384 MB/s modeled byte path | Different execution model |
| Cluster / path throughput | 20.28 GiB/s projected 3 independent 8-vCPU workers · 24 vCPU total | 384 MB/s | ~56.7× higher completed-byte rate |
| Raw crypto time to finish 1 PB | ~12.76 hours | ~723.4 hours / ~30.1 days | ~710.6 hours shorter |
| Seconds per completed encrypted GB | ~0.046 s/GB | ~2.604 s/GB | ~56.7× lower |
| Execution style | Parallel stateless workers · serverless orchestration · object/range fan-out · Kafka/event queues | Longer-lived serial or weakly parallel jobs with more product stitching around the byte path | Shorter queues and batch windows |
Same 1 PB. Half a day versus roughly a month.
ΞNIGMA cluster: ~0.046 seconds per encrypted GB. Illustrative PQ byte path: ~2.604 seconds per encrypted GB. That metric survives changes in batch size and makes queue economics visible: every backlog gigabyte clears about 56.7× faster at the modeled cluster rate.
At 384 MB/s per lane, approximately 57 parallel lanes would be required to match ΞNIGMA’s projected ~21.775 GB/s aggregate byte rate. That is a throughput-normalization fact only. The main TCO model below does not multiply the comparison stack by 57; it compares one defined modeled assembled stack against ΞNIGMA on the same 1 PB completed workload.
The 30-day job has a labor cost
Long-running security jobs consume people as well as machines. The model therefore separates standing annual organization cost from active-run coverage. The assembled side carries 6 integration/crypto FTE, 2 audit/compliance/base-SRE FTE, 1 program/security-management FTE and a 0.5-FTE shared HR/People, recruiting, finance/procurement and IT-support allocation. Each full-time equivalent retains the existing $220,000 fully loaded annual planning rate. “Loaded” is intended to include employer healthcare/insurance, retirement, paid leave, payroll taxes and legally required benefits rather than salary alone. Active-run coverage then uses the same two concurrent production FTE on both sides while each 1 PB job remains open.
U.S. Bureau of Labor Statistics ECEC data for private-industry management/professional workers reports $53.50/hour in wages plus $24.59/hour in employer benefits, for $78.09/hour total employer compensation. That is roughly a 46% employer-cost uplift over wages. This benchmark supports treating labor as fully burdened; the $220K/FTE figure remains an illustrative planning assumption, not a universal salary claim.
| Active-run labor | ΞNIGMA · 3 × 8 vCPU | Illustrative PQ byte stack | Difference |
|---|---|---|---|
| Elapsed encryption window | ~12.76 hours | ~723.4 hours | ~710.6 additional elapsed hours |
| Coverage model | 2 concurrent production FTE while job is active | 2 concurrent production FTE while job is active | Same staffing assumption |
| Allocated FTE-hours | ~25.5 hours | ~1,446.8 hours | ~1,421.2 additional FTE-hours |
| Allocated run labor | ~$2,698 | ~$153,023 | ~$150,324 more labor consumed |
This is an allocated active-run operating burden, not a claim that every customer literally staffs two people at a console for every second. Serverless orchestration and Kafka/event-driven execution can reduce hands-on oversight further; using identical two-person coverage on both sides keeps the time penalty visible without giving ΞNIGMA a staffing-assumption advantage.
1 PB full-stack TCO
The 1 PB model does not freeze the comparison stack at its 300 TB cost. The workload is 3.33× larger, so the comparison-side encryption platform, PQ / crypto-agility layer, KMS / HSM capacity allowance, and active-run labor scale with volume or runtime. The model now also makes the standing labor organization explicit: 6 integration/crypto FTE + 2 audit/base-SRE FTE + 1 management FTE + 0.5 shared corporate-support FTE, all at the existing $220K fully loaded planning rate. Integration and base operating roles remain annual standing costs rather than being multiplied 3.33×. These are planning assumptions, not named-vendor quotes.
| Annual cost element | ΞNIGMA 3.01 PB @ $3/GB | Modeled assembled stackvolume-sensitive components scaled to 1 PB |
|---|---|---|
| Encryption platform | $3,000,000 1,000,000 GB × $3/GB | $5,000,000 300 TB allowance scaled 3.33× to the 1 PB workload |
| PQC / crypto-agility | Included adjunct capability | $1,666,667 Volume/capacity-sensitive allowance scaled 3.33× from the 300 TB model |
| KMS / HSM security program | Customer-controlled key systems; common external charges excluded | $2,000,000 Protected custody / HSM capacity allowance scaled 3.33× from the 300 TB model |
| Integration + crypto engineering | Integrated product boundary | $1,320,000 6 FTE × $220,000 loaded |
| Audit, compliance + base SRE | Integrated evidence / API model; customer base labor excluded | $440,000 2 FTE × $220,000 loaded |
| Program / security management | Integrated product/support boundary; customer program-management labor excluded | $220,000 1 FTE × $220,000 fully loaded |
| Shared corporate support | Customer HR / recruiting / finance / IT overhead excluded | $110,000 0.5 FTE equivalent × $220,000 loaded-equivalent across HR/People, recruiting, finance/procurement and internal IT support |
| Recurring infrastructure ownership + maintenance | ~$7,385 3 × 8-vCPU Cobalt proxy for the modeled workload | $400,000 Annual planning allowance: refresh reserve + OEM maintenance/support + rack/UPS/network/facility + spares/repair logistics + power/cooling |
| Active workload coverage | ~$2,698 ~25.5 FTE-hours across the ~12.76-hour window | ~$153,023 ~1,446.8 FTE-hours across the ~30.1-day window |
| Modeled annual TCO | ~$3,010,083 | ~$11,309,690 |
Completed-workload economics
| Measure | ΞNIGMA 3.0 | Modeled assembled stack | ΞNIGMA advantage |
|---|---|---|---|
| Completed encrypted workload | 1 PB | 1 PB | Same protected petabyte |
| Time to finish 1 PB | ~12.76 h | ~723.4 h / ~30.1 d | ~710.6 h shorter |
| Allocated active-run labor | ~$2,698 | ~$153,023 | ~$150,324 lower |
| Recurring infrastructure ownership / maintenance allowance | ~$7,385 | ~$400,000 / year | ~$392,615 lower in this model |
| Annual TCO | ~$3.010M | ~$11.310M | ~$8.300M lower |
| TCO / completed encrypted GB | ~$3.01/GB | ~$11.31/GB | ~$8.30/GB lower |
| Relative annual TCO | 26.6% of modeled comparison TCO | 100% | ~73.4% lower |
The $400K infrastructure line is annual, not a one-time box purchase. It represents the modeled carrying burden of keeping the comparison lane supportable: refresh/depreciation reserve, OEM maintenance/support contracts, rack/UPS/network/facility allocation, spares and repair logistics, plus electricity. For power transparency, the expanded model treats 7.9 kW as IT load and applies the Uptime Institute 2025 weighted-average PUE of 1.54. That yields about 12.17 kW total facility draw while active.
Across the comparison's ~723.4-hour / 30.1-day 1 PB run, that is approximately 8.8 MWh of facility energy, including about 3.1 MWh attributable to cooling/power-distribution overhead. If the lane is maintained continuously ready for service, the same load annualizes to about 106.6 MWh/year, including 37.4 MWh/year of non-IT overhead. At the U.S. EIA May 2026 commercial average of 13.54¢/kWh, that always-ready electricity case is approximately $14.4K/year. Electricity is only one component of the broader $400K/year modeled infrastructure carrying allowance.
Five-year perspective: the existing infrastructure allowance alone is about $2.0M over five years before platform software, PQ, KMS/HSM or people. In the illustrative always-ready power case, facility energy is about 532.9 MWh over five years. These are planning-model outputs, not named-vendor quotes. ΞNIGMA cloud power was not directly instrumented, so the site does not claim a direct energy- or CO₂-reduction percentage.
Why queue-driven execution compounds the advantage
| Operating property | ΞNIGMA model | Illustrative slower stack |
|---|---|---|
| Work unit | Stateless object or byte-range job. | Longer-running encryption process with more state and product boundaries around it. |
| Fan-out | Independent Cobalt workers can process disjoint jobs/ranges in parallel. | Scaling requires more slow byte-path instances plus the surrounding PQC/KMS/orchestration stack. |
| Serverless orchestration | Jobs can be launched on demand and retired when the queue drains. | Longer job duration holds compute, process state, and operational attention for much longer. |
| Kafka / event queues | Events can enqueue work continuously; completed GB/s determines how fast the backlog disappears. | At 384 MB/s, the same backlog clears about 56.7× more slowly than the modeled three-worker ΞNIGMA cluster. |
| Operational result | Large workloads complete in a short batch window. | Comparable workloads occupy roughly a 30-day modeled window at the comparison byte rate. |
Closest public alternatives
| Platform / component | Strongest overlap | What still has to be assembled for the ΞNIGMA-style operating model |
|---|---|---|
| Thales CipherTrust | Enterprise key management, transparent encryption, tokenization, cloud key control, hybrid deployment. | Operation-specific K3Y/Trust lifecycle, Particle byte path, PQC adjunct integration, object-job orchestration, unified provenance/evidence model, and one metered API boundary. |
| Fortanix DSM | HSM, KMS, secrets, signing, tokenization, and centralized security controls. | Bulk object-encryption workflow, ΞNIGMA-specific K3Y/Trust model, position-addressable Particle stream, cloud-object execution model, and unified usage/evidence layer. |
| QuSecure QuProtect | PQC migration, crypto-agility, discovery, remediation, and reporting. | Bulk-data byte transformation, K3Y recovery object, FIPS data plane, object I/O/orchestration, metering, and full Trust/provenance lifecycle. |
| Cloud KMS / managed HSM | Protected key storage and cryptographic key operations. | Encryption data plane, PQC layer, job orchestration, policy gates, Trust evidence, operational telemetry, entitlement, and the integration/operations team joining them together. |
Protect the petabyte today. Do not spend the next month processing it.
ΞNIGMA closes the modeled 1 PB cryptographic workload in ~12.76 hours on the projected three-worker cluster. The illustrative 384 MB/s comparison path takes ~723.4 hours / ~30.1 days — leaving infrastructure and operational coverage committed for roughly 710.6 additional hours.
The strongest claim here is completion time, not a universal vendor-speed claim. ΞNIGMA's 6.76 GiB/s 8-vCPU worker result is measured; the 20.28 GiB/s three-worker number is the explicitly labeled linear projection. The 384 MB/s comparison rate remains a favorable planning assumption rather than a named-vendor benchmark. The 57-lane figure appears only as a throughput-capacity note and is not used to calculate the main TCO comparison. The assembled-stack cost model scales the volume/capacity-sensitive platform, PQ, and KMS/HSM allowances by 3.33× from 300 TB to 1 PB. Its standing labor model is explicit rather than hidden: 6 integration/crypto FTE, 2 audit/base-SRE FTE, 1 program/security-management FTE, and 0.5 shared corporate-support FTE-equivalent at the existing $220K fully loaded planning rate, plus identical two-person active-run coverage while each job remains open. “Fully loaded” includes employer benefit burden rather than salary alone; the BLS March 2026 management/professional compensation data is used only as a reasonableness check. The recurring infrastructure model also stays explicit: its existing $400K/year allowance is treated as a carrying-cost envelope rather than a one-time purchase. The expanded facility-power proxy treats 7.9 kW as IT load, applies Uptime Institute's 2025 weighted-average PUE of 1.54, and uses the U.S. EIA May 2026 commercial electricity average of 13.54¢/kWh. These are illustrative planning assumptions, not named-vendor pricing. Common object storage, network egress, and customer-specific external key-service charges are excluded unless explicitly shown.
Engineering Deep Dive — Stream Architecture Review
ΞNIGMA 3.0 uses a position-addressable keystream engine for bulk payload transformation. Given the same 384-bit randomized Particle origin and block index, the engine reproduces the same 128-byte block; that deterministic addressing is what allows independent workers to process disjoint byte ranges without sharing mutable stream state.
The Particle Engine is a custom construction. This appendix documents the review posture rather than publishing a source map of internal identifiers. FIPS primitives remain responsible for entropy generation and schedule derivation, while the position-addressable integer-mixing path is one layer inside the larger authenticated K3Y / Trust design.
Stream architecture at a glance
384 bits / 48 bytes
x · y · z · r · p · tdomain separated
4 schedule sub-keysposition-addressable
7-word derived state16 × u64
plaintext ⊕ stream| Phase | Primary input | Transformation | Review focus |
|---|---|---|---|
| 1 · Random origin | AWS-LC SystemRandom | Create x, y, z, r, p, t with six separate 64-bit random fills, yielding a 384-bit Particle Origin State. | New random origin per protected operation, short lifetime, and zeroization of transient recovery material. |
| 2 · Schedule | 48-byte Particle origin | Use HKDF-SHA-384 with a fixed domain separator and distinct labels to derive four 64-bit schedule sub-keys. | Deterministic derivation, domain separation, and bounded exposure of seed-derived material. |
| 3 · Refresh | Seed, schedule, block index | Derive the block-local state with a 64-bit avalanche-mixing path based on the SplitMix64 finalizer family. | Diffusion plus direct seeking: the same block index can be derived without replaying every prior block. |
| 4 · Emit | Seven derived state words + step | Build a per-block aggregate and emit exactly 128 bytes as 16 × 64-bit words in fast and mixed tiers. | Whole-state influence, fixed block structure, deeper remixing in the second tier, and temporary-buffer cleanup. |
| 5 · XOR | Byte offset + emitted stream blocks | Map byte ranges to block positions and XOR the generated bytes into the payload. | Aligned chunking, independent workers, O(1)-style position seeking, and predictable parallel execution. |
State, schedule, and block mechanics
| Mechanic | Representation | Engineering interpretation |
|---|---|---|
| Origin randomness | 384 bits = 48 bytes = 6 × u64 | The source performs six separate random fills—one for each Particle coordinate—and assembles them into the per-operation origin. The protected origin is committed into Trust and is not intended for logs or operator inspection. |
| Schedule derivation | HKDF-SHA-384fixed domain separator 4 labeled expansions | Separate labels produce distinct schedule roles while keeping the derivation reproducible. The source treats the fixed label as a domain separator; the schedule remains reproducible because the randomized Particle origin is the protected input; the domain label itself is not secret. |
| State refresh | 7 derived words global term + lane-specific mixing | A shared global influence is computed first, primary lanes remain distinct through different rotations/constants, and later companion lanes cross-feed earlier outputs before block emission. |
| Position addressing | state = f(origin, schedule, block_index) | The refresh step does not depend on replaying accumulated stream history. Any worker can derive the state for its assigned block index directly from the same seed/schedule context. |
| Block emission | 128 bytes = 16 × u64 | Tier 1 favors throughput using the current state and per-block aggregate; Tier 2 reintroduces schedule material and additional mixing. The temporary 16-word buffer is cleared after the output bytes are written. |
| Byte transform | C[offset..] = M[offset..] ⊕ K[offset..] | The generated stream is consumed as transient working material for the XOR transform rather than emitted as a customer-visible artifact. |
Parallel execution and offset handling
| Control | Implementation pattern | Why it matters |
|---|---|---|
| Small-buffer path | Buffers below 256 KiB remain single-threaded. | Avoids Rayon task-spawn overhead when orchestration would cost more than the parallel speedup. |
| Aligned work units | Parallel chunks begin on whole stream-block boundaries. | Each worker starts at a valid deterministic position without partial-block coordination at the boundary. |
| Worker isolation | Each worker creates its own byte-offset view of the engine. | No shared mutable engine state, mutex, or inter-worker stream coordination is required for disjoint ranges. |
| Non-aligned seek | step = N / 128skip = N % 128 | The engine seeks to the containing block, discards the first skip bytes, then continues with full 128-byte blocks. |
| Deterministic ordering | Range work may execute independently while the storage/data-plane layer reassembles or commits output deterministically. | Parallelism changes execution timing, not the byte stream produced for a given seed and offset. |
Engineering controls beyond the stream
| Domain | Control | Observed design pattern |
|---|---|---|
| SECURITY | Zeroized secrets by default | AES keys, K3Y material, private keys, seed material, and temporary sensitive buffers are wrapped in zeroizing containers or explicitly cleared after use. |
| 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 inputs before cryptographic processing. | |
| Clean FIPS and signing boundary | AWS-LC-backed primitives, SHA-384 prehashing, ES384 signing through Azure Key Vault, and explicit signature-format normalization keep standardized cryptographic services identifiable. | |
| Failure-closed orchestration | Unsupported modes, incorrect URI types, missing keys, invalid lengths, vault mismatches, and incomplete K3Y inputs return explicit errors instead of silently downgrading. | |
| DATA PLANE | Provider contracts stay separated | InputSource, OutputSink, and KeyProvider traits isolate storage, output commitment, and key retrieval from the core cryptographic job path. |
| Concurrent reads remain ordered | Blob ranges can be downloaded concurrently and measured independently while the consumer still receives a deterministic continuous stream. | |
| Backpressured, commit-gated writes | Bounded channels, configurable block sizes, concurrent uploads, queue/in-flight counters, and final block-list commit prevent success from being reported before storage is complete. | |
| Telemetry proves the execution | QSCC instrumentation records bytes, wall time, throughput, chunk/range timing, queue depth, block timing, and commit duration at the same boundaries where the work occurs. |
The Particle Engine is the mechanism that generates ΞNIGMA’s full-length operation-specific XOR stream on demand. Each new encryption independently samples a fresh Particle Origin State; Particle generates the payload-matched stream only as bytes are processed, generated stream bytes remain transient, and authorized recovery restores the protected state and recreates the identical operation-specific stream by position. Particle is the custom application stream layer—not a classical information-theoretic OTP—while entropy generation, derivation, authenticated Trust sealing, integrity, signing, and optional PQC protection rely on the standardized controls described above.
NIST & FIPS Review
Assessor-facing summary of the cryptographic boundary, implementation evidence, release controls, and standards mapped into the current build. The purpose of this section is to distinguish what is implemented in the product from what still depends on an external certification or authorization process.
Implementation evidence is not the same as product certification. The items below describe algorithms, controls, diagnostics, build practices, and runtime behavior present in this release. They do not, by themselves, claim an independent CMVP validation for the complete ΞNIGMA product or a program-level authorization package.
Implemented control map
| Review area | Implemented posture | Evidence available to an assessor |
|---|---|---|
| FIPS core boundary | AES-256-GCM, GMAC, HKDF, ECDSA-P384, and DRBG are explicitly separated from optional post-quantum adjuncts and mapped to the AWS-LC-backed FIPS path. | Runtime health output, API behavior, pinned provider dependency, KAT surfaces, and build configuration. |
| Integrity & release control | Per-chunk GMAC, authenticated K3Y/Trust handling, signer validation, and fail-closed recovery checks gate plaintext release. | Trust artifacts, decrypt/unwrap behavior, negative gate tests, signatures, integrity records, and status output. |
| PQC adjunct | ML-KEM, ML-DSA, and SLH-DSA are additive controls; they do not replace the classical FIPS core. | Feature-gated key paths, encrypt/decrypt/unwrap flows, Trust stack flags, and PQC KAT coverage where enabled. |
| Operational auditability | Key URIs, K3Y artifacts, redacted Trust output, health/KAT endpoints, and automated validation create reviewable evidence paths. | Release logs, Trust JSON, K3Y/unwrap outputs, health reports, KAT reports, and test artifacts. |
Release engineering evidence
| Area | Current release controls | Review mapping |
|---|---|---|
| SBOM & supply chain | SPDX 2.3 and CycloneDX SBOMs are generated per release; checksums cover the binary and SBOM artifacts; the release workflow signs the checksum set. cargo deny ... --locked and cargo audit --locked gate dependency/advisory posture. | CM-8 · SA-12 · RA-5 |
| Container baseline | Multi-stage build, minimal Debian-slim runtime, non-root UID 10001, read-only production posture, no host mounts, AMD64/ARM64 build outputs, pinned Rust toolchain/dependencies, and AWS_LC_RUST_FIPS=1 at build time. | AC-6 · CM-2 · CM-2(1) · IL6/FedRAMP readiness |
| Rust implementation | aws-lc-rs = "=1.17.0" is pinned; seed-bearing and scratch material use zeroize; the cryptographic hot path avoids unsafe; position-addressable generation enables lock-free parallelism; PQC is feature-gated; TLS uses rustls. | SC-13 · SA-11b · IA-5 |
| Automated validation | Coverage includes ECDSA stack roundtrips, AAD collision/boundary behavior, known-answer vectors, nonce uniqueness, Particle-key safety properties, and in-binary encrypt→decrypt fitness testing. The operator harness also exercises release-build health, roundtrip, gate-failure, unwrap, metering, and re-encryption paths. | SA-11 · SI-2 · AU-2 |
Standards implementation map
| Standard / control family | How it appears in the current build | Product status | Review note |
|---|---|---|---|
| FIPS 140-3 posture runtime cryptographic boundary | FIPS-gated crypto path, AWS-LC-backed primitives, and health/API surfacing of the configured posture. | Implemented | Complete-product CMVP scope and certificate status are external to this document. |
| NIST SP 800-90A DRBG usage | Randomness path used for per-operation Particle seed generation and nonce-generation inputs. | Implemented | Review should trace runtime configuration and provider boundary as part of the FIPS assessment. |
| FIPS 186-5 ECDSA-P384 | Primary Trust signature baseline, with optional secondary ECDSA and decrypt-time pin/verify behavior. | Implemented | Classical signing remains the baseline authentication path. |
| FIPS 203 ML-KEM / Kyber-768 family | Optional K3Y wrap/unwrap adjunct exposed through PQC key references and runtime flow. | Optional adjunct | Additive to the FIPS core; feature and deployment scope must be reviewed separately. |
| FIPS 204 ML-DSA | Optional Trust signature adjunct with verification during decrypt/unwrap when present. | Optional adjunct | Operates alongside the ECDSA baseline rather than replacing it. |
| FIPS 205 SLH-DSA | Optional stateless hash-based Trust signature adjunct with verification on decrypt/unwrap when present. | Optional adjunct | Provides a second PQ signature family for implementation diversity. |
| CMVP / program authorization | External certification, authorization, evidence packaging, and deployment-specific scope decisions. | External process | Not implied by the implementation checklist above. |
The review package is strongest when treated as implementation evidence: a clearly separated FIPS core, optional PQC adjuncts, explicit recovery/integrity controls, reproducible release artifacts, and automated validation surfaces. Formal product validation or program authorization should be tracked as a separate external workstream with its own scope and evidence requirements.
Onboard in under 10 minutes on Azure.
Once the ΞNIGMA service, Azure Blob Storage, Key Vault, and an authorized bearer token are available, the first protected object follows a four-step application workflow: provision references, point to the object, encrypt, then verify recovery and Trust evidence.
What must already exist
| Azure / service dependency | Quick-start requirement |
|---|---|
| ΞNIGMA runtime | Deployed inside the customer Azure boundary and reachable through the configured API endpoint. |
| Blob Storage | A source container for plaintext plus destinations for ciphertext, restored plaintext, and the K3Y artifact. |
| Azure Key Vault | A vault the runtime is authorized to use for the FIPS key references and any enabled PQC adjunct material. |
| Authorization | A valid bearer token and cloud identities/roles that permit the runtime to read and write the referenced resources. |
Four-step application flow
| Step | Action | API / object | Result |
|---|---|---|---|
| 01 | Provision references | POST /v1/keygen | Generate or register the AES, signing, and optional PQC material needed by subsequent operations; retain the returned stable vault references. |
| 02 | Point to the object | az://… URIs | Identify the source object, ciphertext destination, and K3Y destination. Payload bytes remain on the customer-controlled data path. |
| 03 | Encrypt | POST /v1/jobtype = encrypt | Read the source in-boundary, apply the Particle XOR byte transform, generate/seal the K3Y recovery artifact, record Trust evidence, and write ciphertext to the destination URI. |
| 04 | Recover & verify | POST /v1/jobtype = decrypt | Use the corresponding K3Y and required gates to authorize recovery, verify configured integrity/signature controls, reconstruct the Particle stream, and write restored plaintext to Blob. |
Minimal calls
/v1/keygen{
"vault": "pqc-kv",
"prefix": "onboard-demo"
}/v1/job{
"type": "encrypt",
"source_uri": "az://pqc/plain/report.parquet",
"destination_uri": "az://pqc/enc/report.parquet",
"k3y_uri": "az://pqc/k3ys/report.k3y",
"aes_256_gcm_uri": "kv://pqc-kv/onboard-demo-aes"
}Verify the first roundtrip
| Check | Expected artifact / state | What it confirms |
|---|---|---|
| Ciphertext written | az://pqc/enc/report.parquet | The encrypt operation completed and committed the protected object to customer-controlled storage. |
| K3Y written separately | az://pqc/k3ys/report.k3y | Recovery material and Trust evidence remain separated from the ciphertext object. |
| Decrypt succeeds | Restored plaintext object | The matching K3Y, gates, and configured verification controls authorize the recovery path. |
| Payload matches source | Independent digest / byte comparison | The end-to-end encrypt→decrypt roundtrip restored the original object exactly. |
The “under 10 minutes” path is the application onboarding flow, not Azure infrastructure provisioning. Deployment, IAM, network policy, entitlement, and Key Vault/Blob preparation should be completed first. Once those controls are ready, onboarding is intentionally reduced to a small set of API calls and URI references.
DEPLOY IT.OPERATE IT.
Security review, FIPS/PQC posture, Trust/K3Y policy, codes · enforce · info, SIEM/JSON integration, key-system integration, performance validation, and production support.