Construindo uma cifra experimental em TypeScript inspirada em 8 dimensões

Nos últimos dias, comecei um estudo experimental sobre criptografia para entender melhor conceitos como criptografia simétrica, S-Boxes, nonces, difusão, confusão, permutação, efeito avalanche, derivação de chaves e autenticação de mensagens.

Desse estudo surgiu uma ideia experimental chamada Tesseract-8D/128.

O que é o Tesseract-8D/128?

A proposta é explorar um modelo de criptografia no qual cada byte de uma mensagem seja tratado tanto como um valor quanto como um ponto em um espaço de estados de oito dimensões.

Em vez de apenas transformar bytes em uma sequência linear, o algoritmo associa cada byte a uma coordenada dentro de uma estrutura virtual com:

8 dimensões
128 estados por dimensão

Cada byte da mensagem recebe uma coordenada neste formato:

[d1, d2, d3, d4, d5, d6, d7, d8]

Por exemplo:

[12, 87, 4, 126, 31, 0, 92, 55]

Essas coordenadas passam por várias rodadas de transformação com rotações dimensionais, substituições, permutações, difusão e máscaras derivadas da chave. O objetivo é estudar como uma representação multidimensional pode influenciar a confusão e a difusão em uma cifra experimental.

O projeto não pretende substituir algoritmos criptográficos estabelecidos. É um experimento educacional para entender como mecanismos de criptografia funcionam e por que construir criptografia segura é difícil.

A ideia não é afirmar que “oito dimensões” tornam o algoritmo automaticamente seguro. Essa foi uma das primeiras lições importantes da análise:

Uma representação multidimensional, sozinha, não cria segurança criptográfica.

A segurança de uma cifra depende de fatores como:

• Não linearidade forte.
• Difusão e confusão.
• Qualidade do esquema de geração de subchaves.
• Resistência à criptoanálise diferencial e linear.
• Autenticação.
• Uso correto de nonces.
• Análise pública e testes.

O modelo 8D é a inspiração visual e estrutural, mas precisa contribuir de maneira efetiva para a transformação dos dados.

Links do projeto

• Repositório do Tesseract-8D/128 no GitHub.
• Demonstração interativa.

A versão descrita neste estudo: v0.3

Este artigo apresenta o protótipo Tesseract-8D/128 v0.3. Seu formato de saída é:

T8D3:nonceHex:ciphertextHex:tagHex

Nessa estrutura:

• T8D3 identifica a versão do algoritmo.
• nonceHex representa o nonce aleatório gerado para a operação.
• ciphertextHex contém a mensagem cifrada.
• tagHex permite verificar a integridade e a autenticidade do payload com a chave correspondente.

Como a ideia funciona

O fluxo básico de cifragem é:

Um dos objetivos da v0.3 é reduzir o risco de complexidade visual: algo que parece sofisticado, mas pode continuar fraco internamente.

Por isso, essa versão busca fazer a camada 8D influenciar a transformação dos bytes de maneira mais direta.

As principais etapas

1. Conversão em bytes

A mensagem original é convertida em bytes. Por exemplo, o texto:

Hi

Em UTF-8, corresponde a:

[72, 105]

A transformação trabalha sobre esses valores numéricos. Um caractere pode ocupar mais de um byte, como acontece com vários caracteres acentuados e emojis em UTF-8.

2. Nonce

Antes da cifragem, o algoritmo gera um nonce.

Usar nonces diferentes permite que a mesma mensagem, cifrada com a mesma senha, produza saídas diferentes. A geração aleatória busca evitar repetições; não é uma garantia matemática de unicidade.

Exemplo ilustrativo, com valores abreviados:

Mensagem: "Olá"
Senha: "senha-de-exemplo"

Cifragem 1:
T8D3:abc123:...

Cifragem 2:
T8D3:98f7aa:...

A mensagem e a senha são as mesmas, mas o nonce muda entre as operações.

3. Derivação de chaves

A senha do usuário não é usada diretamente. Ela passa por um processo de derivação:

Desse processo são obtidas duas chaves internas:

Essa separação evita usar exatamente a mesma chave nas duas funções.

4. Geração de subchaves: key schedule

A v0.3 usa SHA-512 com separadores de domínio para derivar subchaves destinadas a diferentes operações.

Conceitualmente:

roundKey = SHA-512(
  encryptionKey + nonce + domainSeparator + roundNumber
)

Os identificadores de domínio usados no protótipo são:

T8D-v0.3-round-key
T8D-v0.3-permutation-key
T8D-v0.3-mask-key
T8D-v0.3-tag

A intenção é diferenciar os contextos de uso do material de chave. Os trechos conceituais deste artigo descrevem a ideia; não substituem a implementação completa e sua análise.

5. Coordenadas 8D

Cada byte recebe uma coordenada de oito dimensões com base em sua posição, no nonce, na rodada atual e no material de chave específico daquela rodada:

[d1, d2, d3, d4, d5, d6, d7, d8]

Cada dimensão varia de 0 a 127. Quando uma rotação ultrapassa 127, o valor retorna ao início do intervalo por meio da operação módulo 128:

posição = 126
rotação = +5

resultado = (126 + 5) mod 128
resultado = 3

6. Rotação dimensional

Depois de gerar a coordenada, são aplicadas rotações dimensionais:

Coordenada original:
[12, 87, 4, 126, 31, 0, 92, 55]

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

Resultado:
[17, 96, 6, 5, 32, 4, 95, 63]

Na quarta dimensão:

126 + 7 = 133
133 mod 128 = 5

O valor circula dentro do espaço de 128 estados.

7. Mistura não linear entre dimensões

A proposta é fazer uma dimensão influenciar outra. Na v0.3, as coordenadas são misturadas usando uma segunda S-Box.

Em pseudocódigo, normalizando os índices para uma tabela de 256 posições:

d1 = SBOX_B[(d1 XOR d5 XOR roundKeyByte) mod 256] mod 128
d2 = SBOX_B[(d2 + d6 + round) mod 256] mod 128
d3 = SBOX_B[(d3 XOR d7 XOR maskKeyByte) mod 256] mod 128
d4 = SBOX_B[(d4 + d8 + roundKeyByte) mod 256] mod 128

A coordenada não precisa ser invertida durante a decifragem, porque é recalculada a partir das mesmas entradas:

posição + nonce + rodada + roundKey + maskKey

8. Duas S-Boxes

A v0.3 utiliza duas S-Boxes bijetivas, ou seja, tabelas de substituição nas quais cada entrada corresponde a uma saída distinta:

Também são geradas as tabelas inversas:

INV_SBOX_A
INV_SBOX_B

A inversa de SBOX_A é necessária para desfazer a transformação principal durante a decifragem. A bijetividade permite a inversão, mas não comprova, por si só, a qualidade criptográfica da tabela.

9. Influência direta das coordenadas sobre o byte

Uma das mudanças centrais da v0.3 é fazer a coordenada 8D afetar diretamente o valor do byte.

Conceitualmente:

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

Durante a decifragem, essas operações são desfeitas:

value =
  (value - coordinateAdd - mask) mod 256

byte =
  INV_SBOX_A[value] XOR coordinateXor

Aqui, mod representa o módulo matemático com resultado não negativo. Ao traduzir isso para JavaScript ou TypeScript, é preciso cuidar dos valores negativos, pois o operador % calcula o resto.

Essa etapa faz a camada 8D participar da transformação efetiva dos dados, além do mapeamento visual.

10. Permutação

Depois de transformar os valores, o algoritmo altera a posição dos bytes usando uma permutação bijetiva:

Posições originais:
[0, 1, 2, 3, 4, 5]

Nova ordem:
[4, 1, 5, 0, 3, 2]

Cada posição de entrada precisa corresponder a uma única posição de saída. Se dois bytes fossem colocados na mesma posição, haveria perda de informação e a decifragem não conseguiria recuperar a mensagem corretamente.

Na v0.3, a geração da permutação usa amostragem por rejeição para evitar o viés que uma redução direta por módulo pode introduzir.

Em vez de apenas:

j = random % (i + 1)

O processo usa uma função com esta intenção:

getUnbiasedRandomInt(maxExclusive, randomStream)

11. Difusão

Em seguida, a difusão é aplicada nas duas direções. Primeiro, da esquerda para a direita:

block[i] = block[i] XOR accumulator

Depois, da direita para a esquerda:

block[i] = block[i] XOR accumulator

O acumulador é atualizado usando material de chave e SBOX_B.

O objetivo é estudar o efeito avalanche: uma pequena alteração na entrada deve se espalhar por uma grande parte da saída. Observar esse comportamento é útil, mas não basta para demonstrar segurança.

12. Mistura reversível de blocos

A v0.3 acrescenta uma camada de mistura reversível de blocos. A propriedade esperada é:

inverseMixBlocks(mixBlocks(data)) === data

Essa camada busca ampliar a difusão sem impedir a recuperação dos dados originais.

13. Tag de autenticação

Após a cifragem, é gerada uma tag com HMAC-SHA-256. Ela permite detectar alterações no payload e abrange:

versão + nonce + texto cifrado + dados associados

Se o conteúdo autenticado for modificado, a verificação deve rejeitá-lo. Uma mensagem de erro possível é:

Tag inválida. A mensagem pode ter sido modificada ou a chave está incorreta.

Essa etapa é importante porque cifrar uma mensagem sem autenticação pode permitir que alterações passem despercebidas.

Rastreamento visual

O projeto também inclui uma página que mostra como a camada de permutação desloca uma posição de bit ao longo das rodadas.

A visualização representa apenas o movimento posicional rastreável nessa camada. Ela não foi projetada para exibir:

• Chaves de cifragem ou autenticação.
• Subchaves de rodada ou de máscara.
• Estados internos completos das rodadas.
• Saídas das S-Boxes.

Essa limitação é intencional, mas não deve ser interpretada como garantia de ausência de vazamento de informação.

Depois de substituições, adições modulares, difusão e mistura de blocos, um bit não conserva uma identidade simples: sua influência se espalha pelo estado. Por isso, a visualização se concentra naquilo que pode ser acompanhado de forma direta:

Para onde uma posição de bit se desloca
nas permutações reais de cada rodada.

Modo de hash experimental

O projeto também inclui um modo de hash experimental:

T8D-HASH-512:digestHex

Ele produz um resumo de 512 bits. Esse tamanho de saída não comprova resistência a colisões ou a outros ataques.

O recurso existe apenas para estudo e não deve substituir funções estabelecidas, como SHA-256, SHA-512, SHA-3 ou BLAKE3.

A primeira análise crítica

Depois de construir a primeira versão, pedi uma análise crítica da ideia. O principal ponto levantado foi:

Oito dimensões não aumentam automaticamente a segurança.

Isso faz sentido. Combinar XOR, adição modular, rotação e permutação pode criar uma estrutura visualmente complexa sem garantir resistência a ataques. É preciso analisar a construção completa e as relações entre suas operações.

Esse é o risco da complexidade visual: parecer sofisticado sem oferecer força criptográfica real.

Por isso, a v0.3 concentra o estudo em:

• Fazer a camada 8D influenciar diretamente o valor dos bytes.
• Usar duas S-Boxes.
• Introduzir não linearidade nas coordenadas.
• Melhorar a geração de permutações e reduzir vieses estatísticos.
• Criar testes de avalanche e de entropia.
• Testar mensagens repetidas.
• Analisar padrões no texto cifrado.

O que quero testar

Entre os testes implementados ou planejados estão:

Reversibilidade

Cifrar e decifrar deve devolver exatamente os bytes originais, incluindo textos com acentos, emojis e diferentes comprimentos.

Avalanche da mensagem

Alterar um bit da mensagem deve afetar uma parte significativa do texto cifrado. Para isolar esse efeito no teste, a chave e o nonce precisam permanecer iguais entre as duas amostras.

Avalanche da chave

Alterar a senha deve modificar significativamente a saída. Nesse teste, a mensagem e o nonce ficam constantes para que a comparação observe a mudança na chave.

Comportamento do nonce

A mesma mensagem e a mesma senha, combinadas com nonces diferentes, devem produzir textos cifrados diferentes.

Texto repetido

Mensagens como AAAAAAAAAAAAAA não devem produzir padrões visuais óbvios na saída.

Payload modificado

Alterações nos campos autenticados devem ser rejeitadas pela verificação da tag.

Entropia e distribuição

Analisar a distribuição dos valores de saída ajuda a procurar padrões e vieses. Uma distribuição aparentemente aleatória, porém, não demonstra que a cifra resiste à criptoanálise.

Tecnologias utilizadas

A implementação está sendo construída com:

Vite
TypeScript
Web Crypto API
PBKDF2
SHA-512
HMAC-SHA-256
Lucide icons

A proposta é manter o projeto simples, visual e fácil de testar no navegador.

Importante: este projeto não é para produção

Este é um experimento educacional. Ele não deve ser usado para proteger dados reais.

Algoritmos seguros exigem análise especializada, revisão pública, tentativas de ataque e validação. Usar primitivas conhecidas em partes da implementação não torna automaticamente segura uma construção nova.

Meu objetivo aqui é aprender e experimentar com criptografia simétrica, nonces, derivação de chaves, S-Boxes, confusão, difusão, permutações, efeito avalanche, autenticação de mensagens e fundamentos de criptoanálise.

O que aprendi com o experimento

O Tesseract-8D/128 começou com uma ideia visual:

E se uma mensagem pudesse ser transformada como se estivesse percorrendo um espaço de oito dimensões?

Durante o estudo, ficou claro que a representação visual não é suficiente. Para a proposta se tornar interessante do ponto de vista criptográfico, ela precisa ser avaliada em termos de não linearidade, difusão, geração de subchaves, autenticação, padrões estatísticos e resistência a ataques.

O projeto ainda está longe de ser uma cifra segura, mas já se tornou um exercício valioso para entender como sistemas de criptografia são construídos e por que criar a própria criptografia é tão difícil.

Sugestões, críticas e ideias de análise são bem-vindas no repositório do projeto.