The Finite Lab Transform (FLT) and PKI Based Inverter Distribution

Peter Lablans

Introduction

Modern cryptography treats conjugation as a familiar algebraic tool, but only within the narrow confines of field isomorphisms, where 0 and 1 must remain fixed and the automorphism group of GF(2⁸) contains only a handful of possibilities. The Finite Lab Transform (FLT) departs from this orthodoxy by applying conjugation not to the abstract field, but to its computational representation. This shift removes the algebraic constraints, allowing arbitrary n-state bijections —including relocation of the zero and identity elements—and expanding the implementation space from a few isomorphic variants to the full 256! ≈ 10⁵⁰⁰ reversible instantiations. The result is a transformation that preserves the structure of AES while introducing a scale of diversity that conventional field theory does not contemplate.

The exceptional expansion of the solution space of symmetric encryption security like AES-GCM and ChaCha20 (>10⁴⁸⁰) is achieved by:

1. Application of a simple functional transformation
2. Treating computational functions as n-state (n > 2) rather than binary
3. Benefiting from factorial/combinatorial explosion
4. Easy distribution of large parameters by known PKI (Public Key Infrastructure)

How big is the solution space (>10⁴⁸⁰) of the FLT?

Even if each atom in our universe (10⁸⁰) were a quantum computer, running during the lifetime of our universe, you would still be nowhere near exhausting the solution space of the FLT.

0. Preliminaries

The herein described invention (and it is named deliberately an invention and not a discovery) is a computational development. It is based on application of a digital implementation of an n-state reversible inverter. It is not a mathematical construct. In fact, the mathematics were applied post-development as an analysis tool.

Computers do not perform mathematics. A computer is merely a switching machine that switches gates or electronic devices between physical states, usually designated as Low (L) and High (H). No numbers exist inside a computer, neither 0 nor 1, nor logic states such as False and True. These are all concepts read into a representation of physical states by humans, but physically do not exist.

Still, operational behavior of these switches can be analyzed by applying mathematical concepts from number theory and especially aspects of Galois Theory or Theory of Finite Field operations.

Finite Fields

It is assumed that the reader is at least somewhat familiar with Finite Fields (often expressed as GF(n)) as used in for instance the Advanced Encryption Standard (AES) (NIST FIPS-197).

A finite field GF(n), also called a Galois Field, is defined by a set of n elements that are operated on by two so-called Laws of Composition, often called Addition and Multiplication. These Laws of Composition comply with the axioms of a finite field: they are commutative and associative, have inverses, have neutral elements, and distribute. The neutral element for Addition is denoted z and for Multiplication e.

Orthodoxy Bias

The textbooks on Finite Field Theory, including Lidl & Niederreiter: Finite Fields; Roman: Field Theory; and Adamson: Introduction to Field Theory, all define finite fields in such a way that it leaves open the possibility of z ≠ 0 and/or e ≠ 1. However, all quickly provide as examples the standard modulo‑n operations, and Roman actually defines a finite field early as applying to an ordered set.

Accordingly, finite fields having neutral elements z = 0 and/or e = 1 become, perhaps unintentionally, orthodoxy in finite field operations. This is enhanced by the understanding that:

For every prime power q = p^m, there exists (up to isomorphism) exactly one finite field of order q (with m ≥ 1).

The fact that all instantiations of a finite field GF(n) are isomorphic does not mean that instantiations are the same. For cryptography the significance is that instantiations are different, because they generate different outcomes such as ciphertext.

The FLT as described below overcomes that bias and creates different instantiations (or computational implementations) that make successful attacks by brute force factorially more difficult. Furthermore, the FLT leverages factorial explosion, which is commonly underestimated because of its relatively small value of n! when n is small, but explodes for n > 16.

Mathematically Provable Security

An issue that is automatically raised in cryptography and thus in encryption is the idea of mathematically provable security. Fundamentally it means that the computational operations, when described in mathematical terms, are secure. It requires rigorous formal proofs to mathematically demonstrate that the security of a cryptographic scheme is directly linked (reduced) to the assumed hardness of solving a well-established, computationally difficult mathematical problem (intractability).

AES, applying multiple steps, applied the concept of “security margin”. One can find details in the article by Daemen and Rijmen: The Design of Rijndael.

The FLT, as disclosed below, almost immediately gets the challenge: What about provable mathematical security?

Because of the isomorphism between the instantiation of the finite field as in FIPS-197 (“orthodox AES”) and the instantiation created by the FLT, the mathematical security is at least as good as in orthodox AES.

In orthodox AES, the security margin is measured in rounds. In FLT, the margin is extended by factorial instantiation diversity. This makes it provably less likely that an attacker can mount a successful cryptanalytic attack, because they must first guess the instantiation before even attempting to break the key.

Orthodox AES measures its security margin in rounds; FLT extends the margin into factorial instantiation diversity. This reframing makes brute force attacks not just impractical, but combinatorically implausible.

1. Architecture and Implementation

The FLT is a functional computational transformation—a transformation of a computer‑implemented function.

Its foundation lies in the digital design framework developed by Dr. Gerrit “Gerry” A. Blaauw, who distinguished between:

• Architecture: The abstract definition of a system’s behavior.
• Implementation: The specific realization of that architecture.
• Realization: The physical instantiation of the implementation.

Blaauw’s purpose was to create a common architecture that preserves defined outputs across different implementations, ensuring compatibility between generations of machines. This principle is now universally applied in computer design. He was one of the principal designers of the IBM System/360.

FLT applies a “twisted” form of this framework:

• The architecture of a cryptographic system (e.g., AES‑GCM) is preserved.
• The implementation of its functions is modified so that identical inputs (plaintext) yield different outputs (ciphertext).

Its development has been largely computational, with minimal reliance on formal mathematical theory. However, since academic cryptography values mathematical rigor, the FLT can be articulated in the language of classical number theory.

1.1 FLT as a Structure‑Preserving Conjugation

The FLT is a novel number‑theoretical transformation that injects real‑time, high‑entropy cryptographic agility into existing symmetric ciphers (AES, ChaCha20).

The Finite Lab Transform (FLT) is best understood not as a new cipher, but as a Master Key that can dynamically change the internal functionality of an existing cipher like AES‑GCM, while leaving the wiring unchanged.

Imagine current AES as a massive, complex engine. Every time you run the engine today (encrypt a message), it uses the exact same gears (the implementation) to get the result. Attackers study this static gear structure.

FLT works by introducing a secret set of high‑entropy modifications of core functionality that preserve the important properties of the function but modify its numerical (computational) output.

Cryptographers will recognize the FLT as a structure‑preserving conjugation, a concept from abstract algebra. For non‑specialists, a key insight is that the transformations do not simply cancel each other out in the context of the cipher’s internal mathematics.

1.2 Formal Mathematical Definition

Let:

• g: a base finite‑state operation (e.g., addition or multiplication modulo n)
• h: a secret, arbitrary n‑state reversible inverter (permutation)
• S = {0, 1, …, n − 1}: the finite set of states

Define: f = h⁻¹ ∘ g ∘ h.

For a 2‑operand operation g(a, b) = c, the transformed operation is: f(a, b) = h⁻¹(g(h(a), h(b))).

Key Components:

• g: Original operation (e.g., XOR, addition over GF(n)).
• h: Secret permutation chosen from n! possible maps (the computational inverter).
• h⁻¹: Inverse permutation.
• f: FLT‑transformed operation—structurally identical but numerically distinct from g.

1.3 Isomorphism and Automorphism

Because f is a conjugation of g, it preserves all essential algebraic meta‑properties (associativity, commutativity, invertibility).

1. Isomorphism
   • The algebraic structure defined by f is isomorphic to that defined by g.
   • This ensures functional correctness and cryptographic integrity.
2. Automorphism
   • The resulting f is an automorphic implementation of the original primitive.

1.4 Cryptographic Implications

• The vast space of possible permutations yields a solution space exceeding 10⁴⁸⁰.
• This scale defeats long‑term adversarial harvesting.
• FLT strengthens resilience against both classical and quantum attacks (Shor’s, Grover’s).
• Crucially, it does so by enhancing mature and proven ciphers like AES‑GCM and ChaCha20, not replacing them, and without cumbersome expansion of keys or internal states.

2. The FLT in Detail

This section explains the concept of n-state inverter, reversible n-state inverters and reversing n-state inverters. The n-state reversible inverters enable the implementation of the Finite Lab Transform (FLT). The FLT is demonstrated on lookup tables of 8‑state (3‑bit) operations.

2.1 The n‑state inverters

An n-state inverter is represented by a sequence of n n-state symbols. Each symbol in the sequence has a value (selected from n possible states) and a position in the sequence. For instance: inv_n = [a₀ a₁ … a_n−1].

For convenience, the set of n‑state elements is generally assumed to be {0, 1, 2, …, n − 1}. For instance, 8‑state elements are selected from S₈ = {0, 1, 2, …, 7}.

The position i of a symbol a_i is determined starting at position i = 0.

In computers, symbols don’t exist; only physical states exist (LOW/HIGH). An n-state signal with n > 2 is generally a set (or “word”) of signals. An 8‑state signal may be represented by a 3‑bit word (8 = 2³).

Example 8‑state inverter: inv₈ = [7 0 3 0 6 4 5 5]. This means inv₈(0) = 7, inv₈(1) = 0, …, inv₈(7) = 5. In this example, the inverter has duplicative states and is not reversible.

An n-state inverter is reversible when there is a rule that undoes the inversion. This requires that the inverter has exactly n different elements in n different positions (a bijection). The reversing inverter is denoted rinv, and inv_n(rinv_n(x)) = x.

Example of a reversible 8‑state inverter: inv₈ = [7 0 3 6 2 4 1 5]. The corresponding reversing inverter is rinv₈ = [1 6 4 2 5 7 3 0].

A reversible n‑state inverter is a permutation of the identity invi = [0 1 2 3 … n−1]. There are n! different permutations of invi, including invi itself.

The growth of the number of permutations as a function of n is enormous. While starting relatively slow (2! = 2; 3! = 6; 4! = 24, etc.), n! grows explosively and for n = 256 one has over 10⁵⁰⁰ different permutations. This is factorial (combinatorial) explosion.

2.2 The Finite Lab Transform (FLT)

The diagram illustrates the FLT of a 2‑operand n-state operation. The core operation is c_i = op(a_i, b_i), where a_i, b_i, c_i are n-state elements. The operands a_i and b_i are created by inverting operands a and b, respectively, by an n-state reversible inverter inv_n. The output c_i is inverted with the reversing operation rinv_n.

The FLT transforms the operation op to operation op_f, while preserving all meta‑properties of op. One may represent op in a lookup table. By running through all n input states one may generate the lookup table for op_f. In software this is easy, and for practical applications like n = 256 it occupies relatively little storage (a 256×256 table is 64 KB).

The FLT applies to any 2‑operand n-state operation. That means it applies to operations over a base field GF(q) with q prime, as well as to operations over extension fields GF(q^p). This is unusual, as literature often assumes a single base field GF(q) defined by addition and multiplication modulo q. This has consequences for cryptographic operations such as ECC, Diffie‑Hellman, and RSA.

2.3 Examples for n = 8 of FLTed Look‑up Tables

One application of the FLT is to dramatically enhance security of symmetric encryption like AES‑GCM/CTR and ChaCha20. These primitives work with bytes (AES) and 32‑bit words (ChaCha20). For that reason, examples use n = 2^k. AES‑GCM works on n = 256, but 256×256 tables are unwieldy as examples, so 8‑state tables are shown for viewing convenience.

The tables are related to the addition and multiplication over GF(8). The addition over GF(8) is formed by bitwise XOR of 3‑bit words (2³ = 8) and mapping to decimal. The multiplication is created by polynomial multiplication modulo x³ + x + 1. The addition table is sc₈ and the multiplication table is mg₈.

In sc8, the zero element z = 0 (row/column 0 is identity). In mg8, z = 0 (row/column 0 all zeros) and the multiplicative identity e = 1 (row/column 1 is identity).

There are 40,320 different 8‑state reversible inverters. Selecting inv8 = [5 2 6 7 4 0 1 3] and applying the FLT generates FLTed tables sn8 and mn8.

Reviewing identity rows/columns, one finds z = 5 in sn8 and e = 6 in mn8. And z = 5 in mn8 provides a row/column with all identical elements.

One can check that sn8 and mn8 are associative and distributive, commutative, and have inverses; thus they form a finite field GF(8).

Also, sc8 is a 2‑operand self‑reversing commutative 8‑state function (involution), because: c = sc8(a, b); b = sc8(a, c); and a = sc8(b, c). This property is preserved by the FLT, so sn8 is also a commutative involution.

2.4 Application in AES‑GCM

The Advanced Encryption Standard is the leading encryption primitive globally (NIST FIPS‑197). AES comes in different modes (NIST SP 800‑38A). The most widely used mode is AES in Galois Counter Mode (AES‑GCM) as defined in TLS 1.3 (NIST SP 800‑38D).

AES‑GCM and AES‑CTR use AES to generate a keystream in a one‑way approach. The keystream is combined with plaintext to generate ciphertext, and decryption combines ciphertext with a locally generated keystream. Thus, keystream generation should be repeatable, not necessarily reversible.

AES‑GCM/256 works with a 256‑bit key and an IV. It applies five transformations:

1. Key Expansion: expands the 256‑bit key to a 240‑byte key array.
2. SubBytes(): substitution using an S‑box.
3. ShiftRows(): permutes the state array by rotation.
4. MixColumns(): vector/matrix multiplication.
5. AddRoundKey(): combines the state array with a round key array.

Except for ShiftRows(), all of the above may be further transformed by the FLT.

An FLT modification may be applied in AddRoundKey() in at least one round. The inputs in AddRoundKey() are a 4×4 byte state array and a 4×4 round key array. In standard AES the arrays are combined column‑wise by bitwise XOR (addition over GF(256), sc256). Using an FLT one may transform this into a FLTed 256‑state function sn256, which is also an addition over GF(256).

The effect is illustrated below in the following 256‑state arrays as applied to round 9 in AES‑GCM.

In an AES‑GCM example, the following inputs are applied:
PlainText = “I like to read! I like to read!”
iv = 4392367e62ef9aa706e3e801
key = 44a74c1a57da2bf6d6838956cdca13f1b67cc6ad87d459bff544784083868171

The effect of this change by FLT completely changes the ciphertext that is generated from:
ciphertext_standard = 6deb6e66165c0f8d85369bb6d2051d4ca7f25733d8432306e112413bff4a2a
to
ciphertext_mod = 4813ca8a7a5e6b78c33ba82bf7e90a4d3ed06b02203ed32f471d32e2644dca

This illustrates the significant change imposed by the FLT. It indicates how the imposed change ripples through the entire flow of the symmetric encryption and, combined with AES’s diffusion and confusion, creates a highly secure modification.

One may apply the FLT to the other modules or transformations in AES‑GCM as identified above.

3. Interactive and Dynamic FLT Update

Repetition is the enemy of cryptographic security. An FLT that depends on a pre‑stored n‑state reversible inverter is less secure than an FLT that is created per cryptographic session, for instance.

3.1 PKI Based Inverter Generation

US Patent 12,476,789 addresses that issue. Keep in mind that a 256‑state reversible inverter has 256 different 256‑state elements. The method:

1. A shared sequence of n‑state elements (e.g., 32 bytes) is received.
2. The shared sequence is expanded to at least 256 bytes; it will have duplicate bytes and missing bytes.
3. Replace duplicate bytes with missing bytes.
4. A 256‑state reversible inverter well be created and may be applied in an FLT.

A 32‑byte sequence is a 256‑bit sequence. Such a shared sequence may be created as part of a PKI process between two computers. A PQ‑secure PKI key generation process is, for instance, Kyber (NIST FIPS 203).

Thus, a PKI‑based method has been provided that applies a tested (and in this case PQ secure) key exchange mechanism to establish a common 256‑state reversible inverter. This can take place per cryptographic session. One can use the PKI key for both shared key and inverter generation, or use multiple key generations (one for a symmetric key and one for an n‑state reversible inverter). TLS 1.3 already supports multiple keys and can be extended.

3.2 Self‑propagating Inverters

Repetition is the enemy of security. To prevent repetition, an n‑state inverter can generate its own successor:

Using the Matlab expression invn = invn(invseed) for self‑propagation. Initialize invseed and invn with, for instance, the 256‑state reversible inverter generated from a shared key.

Example 8‑state inverter inv8 = [4 2 1 5 6 3 7 0]. Applying invn = invn(invseed) generates in 3 consecutive cycles, generates:

inv81 = [6 1 2 3 7 5 0 4]
inv82 = [7 2 1 5 0 3 4 6]
inv83 = [0 1 2 3 4 5 6 7]
  

For relatively short n‑state reversible inverters, the cyclic nature of self‑propagation limits the number of different inverters. But for larger n (e.g., n > 200) one can routinely generate hundreds of millions of different inverters by self‑propagation, up to over a billion for n = 256.

A simple way to further secure extremely large cycles is to generate a 512‑state reversible seed inverter. Self‑propagation is achieved by invn = invn(inv512), and the resulting 512‑state inverter is reduced to a 256‑state inverter by dropping all elements > 255. The cycle length for n = 512 is generally > 1 billion.

This approach allows real‑time change of encryption implementation, per session, per message, per packet, and per block, if desired.

4. Other Transformations/Modifications

The FLT as explained above is one of several transformations that expand or enhance the solution space of cryptographic primitives. Following are more, without detailed explanation.

Radix‑n transformation

The addition over GF(2^k) is carry‑less. One may include a reversible carry‑propagating function. In AddRoundKey() in AES, one operates on columns of 4 bytes. One may consider that as a carry‑less addition: [c0 c1 c2 c3] = [a0 a1 a2 a3] + [b0 b1 b2 b3]. Transforming this into a carry‑propagating (radix‑n) addition creates sums that are significantly different from those created by carry‑less addition.

Radix‑n transformation with random carry

A carry‑propagating addition, like ripple carry, seems to require a fixed carry function. This is not the case in cryptography. In AES‑GCM the AES portion is used for keystream generation and doesn’t have to be reversible. However, it must have an output (sum‑space) that is unbiased for any input. As long as the residue‑generating function is reversible, one may select any random carry function and maintain a sum‑space with uniform distribution of outcomes.

2‑operand n‑state involutions not being addition over GF(n = 2^k)

The XOR‑based, self‑reversing addition over GF(2^k) is a 2‑operand commutative involution and is ubiquitous in cryptography. It is the final function in AES‑GCM and ChaCha20 that combines plaintext/ciphertext with a keystream. One can construct 2‑operand n‑state involution operations that are not additions over GF(2^k) and provide different outcomes.

Extremely large bit‑sequence reversible inverters

Some cryptographic primitives use elements represented by hundreds or thousands of bits. Creating n‑state inverters seems daunting. One relatively simple approach is the use of n‑state maximum length feedback shift registers (FSR).

The content of a k‑state shift register is a set of n‑state elements being inverted. For instance, a 1024‑state inversion can be achieved with a maximum length 256‑state FSR with four 256‑state shift register elements. An inversion is achieved by running the FSR p steps forward and capturing the new content; the reversing inverter runs the FSR in p steps in reverse. An FLTed FSR may be applied.

One issue herein, is to find primitive polynomials of degree 4 (in the above example) over GF(256). This is easily done in MAGMA Calculator, but requires translating its field notation into an executing program (C, Python, etc.).

Other Modifications

One possible modification to both AES and ChaCha20 is to expand the size of the state array. In AES, the state array is traditionally 4×4×8 = 128 bits. This could be generalized to an N×N array of bytes, where N > 4, increasing the internal state size and potentially strengthening resistance against exhaustive search and certain structural attacks.

Another modification involves altering the unit size of processed words in AES. Conventionally, AES operates on 8‑bit bytes. By extending this to W‑bit words, where W > 8, one could explore new design spaces with larger substitution‑permutation structures.

Yet another modification is increasing the number of rounds.

All of these modifications—expanding the state array, increasing the unit word size, or adding more rounds—ultimately serve as patches rather than true architectural improvements. They do not fundamentally strengthen the underlying structure of the cipher. This mirrors the historical struggle with RSA, where continually increasing the modulus size was necessary to stay ahead of attacks.

This distinction is precisely what makes the Finite Lab Transform (FLT) stand out. It keeps the architecture unchanged, but deeply modifies the functional implementation.

5. Some Limitations

The solution spaces provided by the FLT and others are gigantic, but still finite. The nature of the operations has some inherent repetition. Self‑propagation of inverters for relatively small n may create short or shorter cycles.

One significant limitation is caused by the nature of the addition over GF(2^k). In the 8‑state tables of sc8, sc8(a, a) = z for all a. This inherently limits the number of different functions that can be generated. For small n (n= 4, 8, 16) this is restrictive, but for n = 32 the number of different functions under FLT explodes.

A best estimate of a bound of available distinct additions over GF(n = 2^k) is:

This establishes p = 240 for n = 8; and by “explosion” p = 10²⁸ for n = 32.

For n = 256, the number of different additions over GF(256) is greater than 10⁴⁸⁰, rendering the above limitation irrelevant for practical cryptographic purposes.

The limitations are mentioned to alert potential users to possible duplicates and to carefully watch parameter sizes. With these conditions addressed, one practically will see no effect of duplicates during the lifetime of our universe.

The solution space of the Finite Lab Transform (FLT) is immense, and can be further expanded by introducing multiple points of transformation within a cryptographic primitive. These enhancements are multiplicative, pushing the effective solution space beyond astronomical magnitudes.

Yet, in cryptography, sheer solution space size is only one (albeit important) dimension of security. Equally critical is theoretical resistance against mathematical analysis (cryptanalysis). Preliminary evaluations using Hamming distance metrics demonstrate excellent diffusion and nonlinearity properties, strengthening resilience against statistical attacks.

Side‑channel vulnerabilities, such as timing analysis, can be mitigated through equal‑time realization of inverters and operations. This defense is reinforced when all computational steps are implemented with uniform timing, including those that perform no modification (identity inverters). Under this design, an adversary cannot distinguish whether an FLT modification has been applied.

As cryptographic history illustrates, disciplined operational practices are as vital as the choice of secure primitives. The FLT framework, when combined with rigorous operational safeguards, offers a promising foundation for robust cryptographic design.

6. It Works!

Yes, it works—without qualification. By consistently using lookup tables, side‑channel attacks do not expose the FLT. One should employ a lookup table together with identity inverters when no change is desired. This ensures that all variations execute at the same speed.

Standard cryptographic primitives have been successfully transformed using the FLT, including both encryption and hashing. Reference implementations in Python and Matlab are available for trial, educational, and research purposes only, and may be downloaded from: https://lcip.in/.

7. Info + Contact

One may look up the patents in the USPTO Patent Database or in Google Patents. For additional information send a request to [email protected].

8. Intellectual Property (IP) Rights

The author retains all copyrights to this article. Copying and distribution are permitted provided that the source is clearly acknowledged. Any reproduction, whether partial or complete, must include proper attribution to the original author.

The inventions disclosed herein are protected by a substantial U.S. patent portfolio. Permission is granted to use these inventions strictly for educational, testing, research, and other non‑operational purposes. Any operational use in computer‑implemented cryptographic processing of messages or data is expressly prohibited.

A single‑user operational license, as described on https://lcip.in/, is required for any such use. The fees for a life-long license for a single individual identifiable user as of January 25, 2026 is $259. See for some details here.