INETERNUM: What Happens When the Key Is Designed to Disappear?

Human Blooming’s latest cryptographic architecture started with experiments on IBM quantum hardware. It ended somewhere far more immediately deployable: a commercial computer, an RTX 5090, a TPM, physical timing phenomena, causal history — and a 32-byte secret designed to disappear.

There is a question at the heart of modern cryptography that is so familiar that it is rarely questioned.

How do we protect the key?

We put it behind access controls. We wrap it with another key. We place it inside an HSM. We rotate it. We back it up. We build increasingly sophisticated infrastructure around the assumption that the secret must remain available because, at some point, we will need it again.

Human Blooming’s INETERNUM starts from a different question:

What if the safest place for a cryptographic secret, once it has completed its job, is nowhere at all?

That sounds simple. The engineering required to make it real is not.

INETERNUM is the result of an experimental path that has crossed IBM quantum processors, physical randomness, CPU and GPU timing, entropy assessment, Windows cryptography, TPM hardware, causal state, authenticated encryption, memory management, deliberate secret destruction and a second architecture devoted entirely to preserving evidence of what happened after the secret itself has ceased to exist.

The final system does not require a quantum computer. It runs on conventional commercial hardware.

And in its published test, a 32-byte ephemeral physical root governed an authenticated 4 GiB encryption workload in 3.37367 seconds: 1,273.08 MB/s, while the documented round-trip, wrong-key rejection, tamper rejection, memory-locking and root-zeroization gates passed and no persistent key file was created.

But the speed is not the most interesting result. The architecture is.

It began on IBM Phoenix

The story starts somewhere considerably less conventional.

Human Blooming’s earlier experiments used ibm_phoenix, IBM’s superconducting quantum hardware, not simply as a remote random-number generator but as a laboratory for studying physical response.

Across a series of workloads, the experiments moved through different circuit geometries, numbers of PUBs and shot depths, including highly concentrated measurement regimes and syndrome-like structures. That distinction matters.

A serious entropy investigation cannot simply search for outputs that look random. It also has to understand structure, concentration, stability and failure modes.

One later Phoenix event became the physical reference point for the early cryptographic architecture: 4,096 shots, 32 measured bits per shot, 131,072 measured bits in total, with a reported fraction of ones of 0.49520111083984375.

The raw measurement was not published. Its identity was instead fixed by a SHA-256 commitment:

41f7c2f584fc712e9d82be6b65d5769f4c74d2b7468368d6ea25421d503ad026

Human Blooming then did something methodologically useful: it kept that physical event fixed while changing the cryptographic architecture around it.

First came the IBM-derived contribution. Then IBM combined with Windows BCryptGenRandom. Then IBM combined with TPM participation.

The quantum experiment was becoming an architectural experiment. And then came the important move. Human Blooming took the idea home.

From a QPU to a laptop

INETERNUM’s operational architecture does not depend on access to IBM Quantum.

The physical layer was progressively internalised into a conventional local machine.

CPU behaviour became observable physical/computational material. GPU execution timing became another channel. Windows supplied its operating-system CSPRNG. A TPM supplied hardware-rooted participation. And the GPU documented in the experiments was not an exotic research accelerator. It was an NVIDIA RTX 5090 Laptop GPU.

The evidence records CUDA 12.8 and PyTorch 2.11.0+cu128. CPU, GPU, operating system and TPM coexist on the local platform. This is where INETERNUM becomes particularly interesting outside a research context.

The transition from Phoenix to local hardware was not simply a substitution of one randomness source for another. It was a transfer of an experimental philosophy.

Observe a physical process. Characterise it. Reject obviously unhealthy behaviour. Condition what is accepted. Quantify what can conservatively be credited. Combine heterogeneous contributions. Bind the result to the event in which it exists. Use it. Destroy it. Preserve the proof.

The physics did not disappear when the QPU disappeared. It changed substrate. And the resulting architecture became locally sovereign.

The RTX 5090 has two jobs

The architecture has an elegant detail. The GPU occupies two conceptually different worlds.

It is part of the machine being observed, and part of the machine doing work.

INETERNUM records host-observed CUDA execution latency as a physical/computational channel. In the published sovereign and temporal executions, 1,024 GPU observations produce hundreds of distinct timing values.

But the same class of commercial platform is also capable of participating in the high-performance computational environment in which the cryptographic service runs.

In other words, the machine is not merely a container for cryptography. Parts of its dynamic physical behavior become inputs to the process from which cryptographic authority is born. That authority is not accepted on appearance alone. It goes through another layer.

Random-looking is not enough

One of the more important aspects of the INETERNUM evidence is also one of the least spectacular visually.

Human Blooming separates three concepts that are often casually collapsed into one: health testing, conditioning and entropy estimation. They are not the same thing.

A health test looks for gross failures or degeneration in a source. A conditioning function can transform, normalize, and cryptographically diffuse input material. An entropy assessment attempts to quantify, conservatively, how unpredictable that material can actually be considered.

A hash function cannot manufacture entropy that was never there. And a source passing a health gate is not automatically an entropy certification. INETERNUM’s published restart evaluations report conservative results of:

CPU: 1.090746 bits per 8-bit symbol

GPU: 3.278302 bits per 8-bit symbol

Then there is the conditioned dataset.

One million bytes. All 256 possible byte values represented. A SHA-256 of:

8c909d2a0c9ca706c6eb42ba3b704f18914b468ad8ce48ea3e157a466e1cbb12

Its empirical Shannon entropy is approximately 7.99979 bits per byte. That is the beautiful number.

Human Blooming did not publish that as its conservative entropy result. It published 7.096303 bits per byte.

Why? Because the limiting estimate came from the bitstring Compression path, at 0.887038 bits per bit. Multiply that by eight and the more conservative result wins. The system does not select the number that looks best. It carries the restrictive result forward.

The report then documents CPU and GPU entropy budgets of 349.03872 and 419.622656 bits per block, respectively. Those numbers reappear in the audit of the physical-root generator used for the operational benchmark.

That creates one of the most important connections in the entire project:

physical observation → assessment → conservative budget → root generation → real cryptographic operation.

The statistics actually reach the machine.

Then INETERNUM does something stranger

Up to this point, one could describe the project as an unusually integrated physical entropy and ephemeral-key architecture. But that would miss its most distinctive layer.

INETERNUM does not only ask: Where did this root come from? It also asks: Which event does this root belong to?

The temporal architecture introduces a nonce, device context, TPM identity, previous causal state, and a functional schedule. The published model can be expressed conceptually as:

Kₙ = KDF(Pₙ, Dₙ, Oₙ, Tₙ, Hₙ₋₁, Nₙ, Gₙ)

That equation doesn't claim the exact implementation; it is an architectural model. What matters is the idea. The root is not merely supposed to be unpredictable. It is supposed to belong to this machine, this context, this history and this event. Human Blooming tested that proposition in two different ways.

The first was ablation. Remove the CPU contribution: reject. Remove GPU: reject. Remove OS: reject. Remove TPM: reject.

The second was displacement. Change time/context: reject. Change device: reject. Change history: reject. Change functional order: reject.

These tests answer different questions. Ablation asks whether the declared contributors actually matter. Displacement asks whether the result can be transplanted into a different event. And then the architecture goes one step further. It remembers.

History without keeping yesterday’s secret

Two published temporal events are causally connected.

Event one begins from an initial chain state and produces a new chain head. Event two takes exactly that new head as its previous state.

Between the events, the nonce changes. The functional schedule changes. The CPU commitment changes. The GPU commitment changes. The TPM identity changes. The ciphertext changes. The chain head changes. But the previous secret root does not have to become the mechanism of continuity.

This produces perhaps the cleanest description of INETERNUM: cryptographic continuity without secret continuity.

Or, formally:

Eₙ → { Sₙ, Hₙ, Pₙ }

Sₙ → ∅Hₙ → Eₙ₊₁Pₙ → persistent

There are three different things here. Secret state. Causal state. Evidence state.

The secret is meant to die, to disappear. The causal state carries history forward. The evidence state allows the past to remain inspectable. That separation is the conceptual center of INETERNUM.

And then it has to do real work

There is a recurring problem with experimental security architectures. They can become extraordinarily sophisticated demonstrations for protecting extraordinarily small things.

INETERNUM’s final benchmark matters because it attacks that problem directly:

The root is just 32 bytes — 256 bits.

The payload is exactly 4,294,967,296 bytes. Four GiB.

The streaming operation divides it into 256 chunks of 16 MiB. The cipher is AES-256-GCM through OpenSSL EVP.

Total measured time: 3.37367 seconds.

Sustained decimal throughput: 1,273.08 MB/s.

Approximately 1.18565 GiB/s.

And the PASS condition is not simply “it went fast”.

The documented benchmark requires a successful authenticated round-trip, rejection of the wrong key, rejection of tampering, memory locking of the root, zeroization of the root, and no created persistent key file.

Performance, authenticity and lifecycle have to succeed together.

The 32-byte insight

The benchmark also answers an obvious question. If INETERNUM begins with physical phenomena, does the physical entropy source itself have to produce data at more than a gigabyte per second?

No.

And that is a crucial architectural insight. The physical system is not being asked to produce every encrypted byte. It is being asked to create the cryptographic authority that governs them.

Thirty-two bytes of root material can govern four GiB of authenticated symmetric encryption. The ratio between root size and payload is roughly 134 million to one in bytes. The entropy-acquisition rate and the bulk-encryption rate are therefore decoupled. The physics governs the birth of the authority. AES-GCM scales that authority into a service.

This is the point at which a research architecture starts to look like something that could leave the laboratory.

The key does its job. Then it burns.

The word ephemeral is easy to use and surprisingly difficult to implement meaningfully.

A secret can be generated ephemerally and then accidentally survive in a file. A process boundary can create a copy. A convenient recovery mechanism can turn a transient key into a permanent asset.

INETERNUM treats the secret’s lifecycle as part of the cryptographic protocol itself.

The physical-root audit declares a 32-byte root and root_persisted=false. The handoff is designed not to create a key file. Windows VirtualLock is requested for sensitive buffers. Controlled secret buffers are zeroized.

The temporal evidence records zeroization across payload and intermediate CPU, GPU, OS, TPM, binding, pad and recovered material. TPM one-use operations include private-export rejection, signature verification before deletion, key deletion and failed reopen.

The key is not being created so that somebody can carefully keep it forever. It is being created to spend its cryptographic authority.

What remains after the secret disappears?

This is where the architecture becomes unusually interesting. Because destroying secrets creates a paradox.

If everything disappears, how do you prove later that the system worked?

INETERNUM’s answer is effectively to build a second machine alongside the first one.

The first machine is operational:

event → root → cryptographic action → burn

The second is epistemic:

event → commitment → manifest → artifact hash → auditor → ledger → evidence package

One machine performs the cryptography. The other preserves knowledge about the cryptography.

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

Its public hash ledger contains 35 declared entries. The independent recalculation performed for the technical analysis produced 35 matches, 0 missing and 0 mismatches. The distinction is subtle but fundamental.

Evidence is not recovery material.

The system remembers the event. It does not need to remember the secret.

Why this is different from simply using a KMS

It is worth being precise here, because many individual ideas inside INETERNUM have strong precedents.

Ephemeral keys are not new. Hardware roots of trust are not new. Physical entropy is not new. Forward security is not new. Key destruction is not new. Authenticated encryption is certainly not new. Neither are cryptographic commitments or hash chains.

KMS/HSM systems solve an enormously important but different problem: managed custody, recovery, rotation and protection of key material. Forward-secure and key-evolving cryptography explore the security value of changing or destroying old key material. NIST’s entropy-source framework separately formalizes noise sources, health testing, conditioning and conservative entropy assessment.

These are important precedents. But they are also the reason INETERNUM is interesting. Its claim to distinction does not depend on pretending those pieces did not exist.

It comes from putting an unusual number of them into one operational lifecycle: physical/local acquisition; health control; cryptographic conditioning; conservative entropy budgeting; CPU, GPU, OS and TPM participation; device and causal-history binding; functional-order dependency; ephemeral inter-process transfer without a key file; high-throughput authenticated encryption; wrong-key rejection; tamper rejection; memory locking; controlled zeroization; causal continuity; and persistent public evidence designed not to become recovery material.

In the comparative research conducted for HUMAN BLOOMING’s INETERNUM technical report, no published architecture was identified that combines this specific set of properties into an equivalent operational lifecycle.

That is a carefully bounded statement. It is also a remarkable one.

Perhaps the biggest surprise is how ordinary the machine is

The work begins with a quantum processor. Operationally, it ends on hardware you can buy. This is the aspect of the project with the greatest commercial implications.

INETERNUM does not require a quantum computer in the final architecture. It does not require a hypothetical future processor. It does not require a new semiconductor fabrication process.

Its sovereign implementation is built around categories of hardware already present in high-end commercial computing: CPU, GPU, operating-system cryptography and TPM.

That does not mean turning the research prototype into a product is automatic. Production engineering, platform hardening, deployment models, external security review and assurance are separate questions.

But it changes the nature of the route to market.

The central question is no longer: Can the necessary hardware exist?

Much of it already does.

The question becomes: How should this architecture be packaged into a service?

And that is a considerably more immediate engineering problem.

There is also a larger Human Blooming story here

INETERNUM did not appear in isolation. Human Blooming had already been publishing work around physical entropy and what it described as sovereign computation: moving capabilities that normally depend on specialized or external infrastructure into locally controlled computing environments.

INETERNUM takes that trajectory somewhere more concrete. Entropy is no longer merely something to measure. It becomes an input to authority.

Hardware is no longer merely something to benchmark. It becomes part of the event.

The TPM is no longer merely a vault. It becomes a participant.

History is no longer merely a log. It becomes an input into the next cryptographic state.

And evidence is no longer an afterthought generated once the experiment is over. It is part of the architecture.

This is computational engineering as composition. None of the individual instruments needs to be magical. The difficulty lies in making them coexist without one property destroying another.

The conditioning must not be mistaken for entropy creation. The entropy budget must survive into the operational generator. The causal binding must not destroy public verifiability. The process handoff must not quietly create persistent key material. The burn must destroy secret state without destroying evidence. The evidence must prove enough without becoming a backup. And the entire lifecycle must remain fast enough to be useful.

That is the hard part. Not one primitive.

The choreography.

What INETERNUM does not need to claim

The architecture becomes less credible, not more, if its results are stretched beyond their evidence.

INETERNUM does not demonstrate that a privileged attacker controlling the kernel or hypervisor during the live event could never capture a root. It does not demonstrate erasure from every register, firmware component, DMA-capable device, snapshot, or third-party library temporary. Its published entropy work is not the same thing as a formal NIST certification. And 1.273 GB/s is the measured authenticated encryption throughput, not a claim of 1.273 GB/s of physical entropy production.

Those boundaries do not weaken the central result. They define it.

INETERNUM’s proposition is not that a live secret becomes metaphysically impossible to steal.

Its proposition is that cryptographic architecture can deliberately reduce how long secret authority exists, where it is intentionally allowed to persist, and what an attacker arriving later can still find.

The most sensitive moment becomes the live event. After the burn, there is deliberately less to steal. That is a different security geometry.

From protecting keys to designing their mortality

For decades, key-management engineering has understandably concentrated on increasingly sophisticated forms of custody.

INETERNUM asks whether some classes of cryptographic authority should be designed around the opposite property. Not stronger custody.

Finite existence.

The idea would be little more than philosophy if it stopped there.

But Human Blooming now has a documented chain running from QPU experiments on ibm_phoenix, through local CPU/GPU physical observation, entropy assessment and conservative budgets, through Windows and TPM contributions, through causal binding, into a 32-byte transient root, through an authenticated 4 GiB operation at 1.273 GB/s, and finally into controlled destruction and a public evidence package whose own integrity can be checked.

That is why the most important number in INETERNUM may not be 1.273 GB/s. Nor 7.096303 bits per byte. Nor 4 GiB. Nor even 256 bits. The important result is the chain between them.

Human Blooming has taken a collection of technologies normally discussed in different rooms — quantum experimentation, physical entropy, GPU computing, TPM hardware trust, statistical assessment, authenticated encryption, memory lifecycle, causal state and cryptographic evidence — and made them participate in the same story.

The public evidence now shows a substantial part of that story. This creates an intriguing question about what comes next.

Because if this is what Human Blooming is prepared to publish from the visible layer of its work — after its earlier releases around entropy and sovereign computation — then the more interesting question may no longer be whether those research threads connect.

INETERNUM shows that they already connect. The question is: How far does that architecture go when the deeper development stack begins to emerge?

For now, the project leaves behind an unusually concise thesis:

CREATE. BIND. USE. VERIFY. BURN. PROVE.

The secret dies. The history continues. The proof remains.