devLap

Building an Experimental TypeScript Cipher Inspired by 8 Dimensions

typescript dev.to

Over the last few days, I started an experimental study on cryptography with the goal of better understanding concepts such as symmetric encryption, S-Boxes, nonces, diffusion, confusion, permutation, avalanche effect, key derivation, and message authentication.

From this study, I started working on an experimental idea called:

Tesseract-8D/128

The idea behind Tesseract-8D/128 is to explore an experimental encryption model where each byte of a message is treated not only as a value, but also as a point inside an 8-dimensional state space.

Instead of simply transforming bytes in a linear sequence, the algorithm assigns each byte a coordinate inside a virtual structure with:

8 dimensions
128 states per dimension
Enter fullscreen mode Exit fullscreen mode

Each byte of the message is associated with a coordinate in the following format:

[d1, d2, d3, d4, d5, d6, d7, d8]
Enter fullscreen mode Exit fullscreen mode

Example:

[12, 87, 4, 126, 31, 0, 92, 55]
Enter fullscreen mode Exit fullscreen mode

These coordinates are then transformed through multiple rounds using dimensional rotations, substitutions, permutations, diffusion, and key-derived masks. The goal is to study how a multidimensional representation can influence confusion and diffusion in an experimental cipher.

This project is not intended to replace established cryptographic algorithms. It is an educational experiment designed to better understand how encryption mechanisms work and why building secure cryptography is difficult.

The idea is not to claim that “8 dimensions” automatically make the algorithm secure. In fact, this was one of the first important lessons from the analysis:

A multidimensional representation alone does not create cryptographic security.

Security in a cipher depends on factors such as:

  • strong non-linearity;
  • diffusion;
  • confusion;
  • key schedule quality;
  • resistance to differential and linear cryptanalysis;
  • authentication;
  • correct nonce usage;
  • public analysis and testing.

In other words, the 8D model is the visual and structural inspiration, but it must contribute meaningfully to the transformation of the data.

Project Links

GitHub Repository:

https://github.com/RazielID752/Tesseract-8D-128

Live Demo:

https://tesseract-8-d-128.vercel.app

Current Version: Tesseract-8D/128 v0.3

The current version of the prototype is Tesseract-8D/128 v0.3.

The output format is:

T8D3:nonceHex:ciphertextHex:tagHex
Enter fullscreen mode Exit fullscreen mode

Where:

  • T8D3 represents the algorithm version;
  • nonceHex is a unique random nonce;
  • ciphertextHex is the encrypted message;
  • tagHex is used to verify whether the payload has been modified.

How the Idea Works

The basic encryption flow is:

Original message
→ byte conversion
→ nonce generation
→ key derivation
→ 8D coordinates
→ transformation rounds
→ permutation
→ diffusion
→ reversible block mixing
→ authentication tag
→ final payload
Enter fullscreen mode Exit fullscreen mode

The main goal of v0.3 is to reduce the risk of visual complexity.

By visual complexity, I mean something that looks sophisticated but may still be too linear or weak internally.

So v0.3 focuses on making the 8D layer affect the byte transformation more directly.

Main Steps

1. Byte Conversion

The original message is converted into bytes.

Example:

"Hi"
Enter fullscreen mode Exit fullscreen mode

becomes something like:

[72, 105]
Enter fullscreen mode Exit fullscreen mode

Each character is treated as a number.

2. Nonce

Before encryption, the algorithm generates a nonce.

A nonce ensures that the same message encrypted with the same password produces different outputs.

Example:

Message: "Hello"
Password: "123"

Encryption 1:
T8D3:abc123:...

Encryption 2:
T8D3:98f7aa:...
Enter fullscreen mode Exit fullscreen mode

Same message, same password, different encrypted outputs.

3. Key Derivation

The user password is not used directly.

It goes through a key derivation process:

password + nonce → PBKDF2 + SHA-256 → internal keys
Enter fullscreen mode Exit fullscreen mode

From that process, two internal keys are created:

encryptionKey → used for encryption
authKey       → used for authentication/integrity checking
Enter fullscreen mode Exit fullscreen mode

This separation is important because encryption and authentication should not rely on the exact same key material.

4. Key Schedule

Version v0.3 uses SHA-512 with domain separators to derive different subkeys for different purposes.

Conceptually:

roundKey = SHA-512(
  encryptionKey + nonce + domainSeparator + roundNumber
)
Enter fullscreen mode Exit fullscreen mode

The current domain separators are:

T8D-v0.3-round-key
T8D-v0.3-permutation-key
T8D-v0.3-mask-key
T8D-v0.3-tag
Enter fullscreen mode Exit fullscreen mode

This helps avoid reusing the same key material for unrelated internal operations.

5. 8D Coordinates

Each byte receives an 8-dimensional coordinate based on its position, the nonce, the current round, and round-specific key material.

[d1, d2, d3, d4, d5, d6, d7, d8]
Enter fullscreen mode Exit fullscreen mode

Each dimension goes from 0 to 127.

When a rotation exceeds 127, it wraps around using modulo 128.

Example:

position = 126
rotation = +5

result = (126 + 5) mod 128
result = 3
Enter fullscreen mode Exit fullscreen mode

6. Dimensional Rotation

After generating the coordinate, dimensional rotations are applied.

Example:

Original coordinate:
[12, 87, 4, 126, 31, 0, 92, 55]

Shifts:
[5, 9, 2, 7, 1, 4, 3, 8]

Result:
[17, 96, 6, 5, 32, 4, 95, 63]
Enter fullscreen mode Exit fullscreen mode

For the fourth dimension:

126 + 7 = 133
133 mod 128 = 5
Enter fullscreen mode Exit fullscreen mode

The value wraps around inside the 128-state space.

7. Non-Linear Dimension Mixing

The idea is that one dimension should influence another.

In v0.3, this is no longer only conceptual. The coordinates are mixed using a second S-Box.

Conceptual example:

d1 = SBOX_B[d1 XOR d5 XOR roundKeyByte] mod 128
d2 = SBOX_B[d2 + d6 + round] mod 128
d3 = SBOX_B[d3 XOR d7 XOR maskKeyByte] mod 128
d4 = SBOX_B[d4 + d8 + roundKeyByte] mod 128
Enter fullscreen mode Exit fullscreen mode

The coordinate itself does not need to be reversed during decryption because it is recalculated from the same inputs:

position + nonce + round + roundKey + maskKey
Enter fullscreen mode Exit fullscreen mode

8. Two S-Boxes

Version v0.3 uses two bijective S-Boxes:

SBOX_A → used for the main byte transformation
SBOX_B → used for masks, coordinates, dimensional mixing, and auxiliary diffusion
Enter fullscreen mode Exit fullscreen mode

It also generates inverse S-Boxes:

INV_SBOX_A
INV_SBOX_B
Enter fullscreen mode Exit fullscreen mode

The inverse of SBOX_A is required for decryption.

9. Direct 8D Influence on the Byte

One of the main improvements in v0.3 is that the 8D coordinate affects the byte value directly.

Conceptually:

coordinateXor =
  d1 XOR d3 XOR d5 XOR roundKeyByte

coordinateAdd =
  SBOX_B[(d2 + d4 + d6 + d8 + maskKeyByte) mod 256]

value =
  SBOX_A[byte XOR coordinateXor]

value =
  (value + coordinateAdd + mask) mod 256
Enter fullscreen mode Exit fullscreen mode

During decryption, this is reversed:

value =
  (value - coordinateAdd - mask) mod 256

byte =
  INV_SBOX_A[value] XOR coordinateXor
Enter fullscreen mode Exit fullscreen mode

This makes the 8D layer more than just a visual mapping. It becomes part of the actual byte transformation.

10. Permutation

After transforming the values, the algorithm changes the positions of the bytes using a bijective permutation.

Example:

Original positions:
[0, 1, 2, 3, 4, 5]

New order:
[4, 1, 5, 0, 3, 2]
Enter fullscreen mode Exit fullscreen mode

The permutation must be bijective:

each input position maps to one unique output position
Enter fullscreen mode Exit fullscreen mode

This is important because if two bytes were mapped to the same position, information would be lost and decryption would not work correctly.

In v0.3, the permutation uses rejection sampling to reduce modulo bias.

Instead of simply doing:

j = random % (i + 1)
Enter fullscreen mode Exit fullscreen mode

it uses a function similar to:

getUnbiasedRandomInt(maxExclusive, randomStream)
Enter fullscreen mode Exit fullscreen mode

11. Diffusion

Next, diffusion is applied in both directions.

From left to right:

block[i] = block[i] XOR accumulator
Enter fullscreen mode Exit fullscreen mode

Then from right to left:

block[i] = block[i] XOR accumulator
Enter fullscreen mode Exit fullscreen mode

The accumulator is updated using key material and SBOX_B.

The goal is to create the avalanche effect:

changing 1 bit of the input should change a large portion of the output
Enter fullscreen mode Exit fullscreen mode

12. Reversible Block Mixing

Version v0.3 also adds an extra reversible block mixing layer.

The important property is:

inverseMixBlocks(mixBlocks(data)) === data
Enter fullscreen mode Exit fullscreen mode

This layer is designed to increase diffusion without breaking decryption.

13. Authentication Tag

After encryption, an authentication tag is generated using HMAC-SHA-256.

The tag is used to detect modifications in the payload.

It authenticates:

version + nonce + ciphertext + associated data
Enter fullscreen mode Exit fullscreen mode

If someone changes even one character of the ciphertext, the tag should no longer match and decryption should fail.

Example error:

Invalid tag. The message may have been modified or the key is wrong.
Enter fullscreen mode Exit fullscreen mode

This is important because encryption without authentication may allow silent manipulation of encrypted data.

Visual Trace

The project also includes a visual page that shows how the permutation layer moves a tracked bit position across rounds.

This visualization only shows the trackable positional movement through the permutation layer.

It does not expose:

  • encryption keys;
  • authentication keys;
  • round keys;
  • mask keys;
  • full internal round states;
  • S-Box outputs;
  • enough information to reverse or attack a message.

This is intentional.

After S-Boxes, modular additions, diffusion, and block mixing, a single bit no longer keeps a clean identity. It becomes influence spread across the state.

So the visualization focuses only on the part that can be honestly tracked:

where a bit position moves during the real round permutations
Enter fullscreen mode Exit fullscreen mode

Experimental Hash Mode

The project also includes an experimental hash mode:

T8D-HASH-512:digestHex
Enter fullscreen mode Exit fullscreen mode

It produces a 512-bit digest.

This is only for study and should not replace real hash functions such as SHA-256, SHA-512, SHA-3, or BLAKE3.

Initial Critical Analysis

After building the first version, I asked for a critical analysis of the idea. The main point raised was:

8 dimensions do not automatically increase security.

And that makes sense.

If the internal algorithm uses only:

XOR
modular addition
rotation
permutation
Enter fullscreen mode Exit fullscreen mode

it may look complex while still being too linear internally.

This is the risk of what I call visual complexity: something may look sophisticated but still fail to provide real cryptographic strength.

Because of that, v0.3 focuses on:

  • making the 8D layer directly influence the byte value;
  • using two S-Boxes;
  • adding non-linearity to the coordinates;
  • improving permutation generation;
  • reducing statistical bias;
  • creating avalanche tests;
  • creating entropy tests;
  • testing repeated messages;
  • analyzing patterns in the ciphertext.

What I Want to Test

Some tests implemented or planned:

1. Reversibility
Encrypting and decrypting must return exactly the original text.

2. Message avalanche
Changing 1 bit of the message should change a large portion of the ciphertext.

3. Key avalanche
Changing 1 character of the password should generate a completely different output.

4. Nonce behavior
Same message + same password + different nonce should produce different ciphertext.

5. Repeated text
Messages like "AAAAAAAAAAAAAA" should not generate obvious patterns.

6. Modified payload
Any change in the ciphertext should invalidate the authentication tag.

7. Entropy
The output should have a distribution close to random.
Enter fullscreen mode Exit fullscreen mode

Technologies Used

The implementation is being built with:

Vite
TypeScript
Web Crypto API
PBKDF2
SHA-512
HMAC-SHA-256
Lucide icons
Enter fullscreen mode Exit fullscreen mode

The goal is to keep the project simple, visual, and easy to test in the browser.

Important: This Is Not for Production

This project is only an educational experiment.

It must not be used to protect real data.

Cryptography is extremely sensitive. Secure algorithms require years of analysis, public review, attacks, tests, and validation by specialists.

The goal here is to learn and experiment with concepts such as:

  • symmetric encryption;
  • nonce;
  • key derivation;
  • S-Box;
  • confusion;
  • diffusion;
  • permutation;
  • avalanche effect;
  • message authentication;
  • basic cryptanalysis.

Conclusion

Tesseract-8D/128 started as a visual idea:

What if a message could be transformed as if it were traveling through an 8-dimensional space?

However, during the study, it became clear that the visual model alone is not enough.

For an algorithm like this to become interesting from a cryptographic perspective, it needs:

  • real non-linearity;
  • strong diffusion;
  • a solid key schedule;
  • authentication;
  • statistical testing;
  • resistance to obvious patterns;
  • critical review.

It is still far from being a secure cipher, but it has already become a great exercise for understanding how modern encryption systems are designed and why creating your own cryptography is so difficult.

If you have suggestions, criticism, or attack ideas, feel free to share them.

Source: dev.to

arrow_back Back to Tutorials