INETERNUM

The full cryptographic lifecycle

The unit of analysis is not IBM Phoenix, the RTX 5090, TPM, SHAKE256, AES-GCM or any individual hash. It is the lifecycle connecting them. INETERNUM coordinates physical observation, health control, conditioning, conservative quantification, multi-source contribution, event binding, ephemeral transfer, authenticated use, controlled destruction and post-burn evidence.

The system is designed so that the secret can die, the causal history can continue, and the proof can remain.

A conventional machine becomes the operational cryptographic platform

The experimental genealogy begins on IBM Phoenix, but the sovereign architecture moves the physical/computational event into local conventional hardware. CPU timing, host-observed CUDA execution latency, Windows BCryptGenRandom and TPM participation are combined on the local platform. The documented GPU is an NVIDIA RTX 5090 Laptop running CUDA 12.8 and PyTorch 2.11.0+cu128.

Phoenix is the experimental laboratory of origin. Sovereign INETERNUM internalizes the paradigm in conventional local hardware capable of creating, using and burning cryptographic authority.

From IBM Phoenix to local physical authority

Six earlier IBM Phoenix workloads document a progression across circuit breadth, shot depth, concentrated response regimes and syndrome-like structures. A later Phoenix event used in the cryptographic line records 4,096 shots × 32 measured bits = 131,072 bits, with a declared one-fraction of 0.49520111083984375 and a raw-measurement commitment fixed by SHA-256.

Conditioning, conservative entropy and operational budgets

INETERNUM separates three questions that are often blurred together: whether a source is behaving acceptably, how observations are cryptographically conditioned, and how much unpredictability can be conservatively credited. Conditioning is not treated as a machine for creating entropy.

The conditioned dataset contains exactly 1,000,000 bytes and all 256 byte values. Its empirical Shannon entropy is approximately 7.99979 bits/byte, while the published conservative result is 7.096303 bits/byte. The limiting path is the bitstring Compression estimate: 0.887038 bits/bit × 8.

The evidence then bridges statistical evaluation to production: the documented CPU budget is 349.03872 bits/block and the GPU budget is 419.622656 bits/block. The same budgets reappear in the physical-root audit used by the final benchmark.

The root belongs to an event, not merely to a random draw

The temporal layer adds nonce, device, TPM identity, prior causal state and a functional schedule. Two linked events show sequence continuity: the first event's new chain head becomes the second event's previous chain head. Across the two events, nonce, schedule, CPU commitment, GPU commitment, TPM identity, ciphertext and chain head change.

4 GiB. 3.37367 seconds. 1,273.08 MB/s.

The final streaming benchmark moves the architecture from small experimental payloads into service-scale authenticated encryption. A 32-byte ephemeral physical root governs an exact 4 GiB workload using AES-256-GCM through OpenSSL EVP.

Physical entropy does not need to run at bulk-encryption speed. The physical event creates authority; symmetric cryptography scales that authority across the workload.

Persistent proof without persistent secret authority

INETERNUM runs two superimposed systems. The operational/causal graph creates and consumes cryptographic authority. The epistemic graph creates verifiable knowledge about what the operational system did.

The public package deliberately retains manifests, ciphertexts, commitments, hashes, audits, statistical results, the conditioned dataset and execution metadata while excluding private keys, pads, seeds, raw CPU/GPU physical samples, plaintexts, source code, executables and credentials.

Properties that emerge from the whole system

A different lifecycle, not a claim that every primitive is new

KMS/HSM systems address custody and managed key lifecycles; TPM provides hardware-rooted key properties; forward-secure and key-evolving cryptography address temporal key evolution; entropy-source standards address health, conditioning and conservative estimation; AEAD provides authenticated encryption. INETERNUM's distinguishing object of study is the integration of these concerns around an event-bound root that is intended to disappear while causal state and non-secret evidence survive.

Comparative research performed for the technical report found clear prior art for individual components and neighboring ideas, but did not identify a published architecture equivalent to the specific integrated lifecycle documented here: local physical acquisition, conservative entropy budgeting, CPU/GPU/OS/TPM contribution, device/history/order binding, ephemeral transfer without a key file, high-throughput authenticated consumption, wrong-key and tamper rejection, controlled memory destruction, causal continuity and persistent public evidence not designed for recovery.

Strong claims require precise boundaries

The public evidence supports the documented protocol lifecycle and its released artifacts. It does not claim whole-machine erasure across registers, kernel, hypervisor, firmware, DMA, snapshots or third-party runtime internals; it is not a formal NIST certification; it does not equate AES throughput with physical entropy throughput; and it does not claim that a live root is impossible to capture by an adversary already controlling the execution environment.

The design target is narrower and concrete: minimize the lifetime and intentional persistence of secret authority, make event dependence testable, and preserve evidence after the secret has fulfilled its function.

Download the evidence