Não é um padrão.Aberto para revisão.
XAES-512 é a evolução do Protectstar Extended AES, lançado pela primeira vez em 2007 — um design derivado de Rijndael com bloco de 512 bits, 24 rodadas e um envelope AEAD moderno. Publicado para que possa ser revisado de forma independente.
Um rascunho de revisão — não um substituto do AES aprovado para uso em produção.
XAES-512 não é uma implementação AES conforme FIPS 197 e não é um substituto drop-in para AES-128/192/256. A versão 2.0 rev4.2 é publicada como rascunho aberto para revisão — para criptoanálise independente, revisão da implementação e feedback da comunidade, não como algoritmo aprovado para uso em produção.
Quatro números que descrevem o design.
XAES-512 pode ser resumido a alguns indicadores-chave — cada um com significado técnico claro, sem qualquer alegação de superioridade.
Como os algoritmos diferem.
O AES padrão, conforme definido no FIPS 197, é excelente e continua sendo a referência. XAES-512 é um design independente, derivado de Rijndael, com um bloco maior — não um substituto, mas uma proposta publicada abertamente para revisão.
* Na medição estrutural de difusão incluída, os deslocamentos ShiftRows {0,1,4,5} atingem difusão completa após 4 rodadas; o padrão ingênuo {0,1,2,3} exige 6 rodadas. Nessa medição, o AES padrão atinge difusão completa após apenas 2 rodadas em sua matriz 4×4 menor. A afirmação sobre difusão pode ser reproduzida com diffusion_check.py; os core KATs também verificam a implementação correta do core cipher.
Um bloco maior por etapa.
Cada célula é um byte. A matriz maior processa mais dados por bloco — e expande o estado interno misturado por cada rodada.
24 rodadas.
XAES-512 usa 24 rodadas em uma matriz de estado 4×16. As rodadas internas seguem o princípio Rijndael de AddRoundKey, SubBytes, ShiftRows e MixColumns; a estrutura exata das rodadas é definida no PDF da especificação.
Três propriedades descritas de forma factual.
Criptografia autenticada
XAES-512 é uma construção AEAD baseada no princípio Encrypt-then-MAC: CTR para confidencialidade, HMAC-SHA-512 para integridade e autenticidade. Mensagens adulteradas são detectadas antes da descriptografia.
Derivação de chaves padronizada
As chaves são derivadas de senhas usando PBKDF2-HMAC-SHA-512 com um salt aleatório por mensagem, seguido por HKDF-SHA-512 para separação de chaves. O perfil 0x02 usa 220.000 iterações PBKDF2; as senhas são codificadas em UTF-8 e normalizadas em NFC.
Aberto e reproduzível
Sem segurança por obscuridade. A especificação, a implementação de referência, os testes de resposta conhecida e as ferramentas são publicados como bundle Apache-2.0 — para que qualquer pessoa possa reproduzir e revisar o design.
A especificação em resumo.
Construção, derivação de chaves, rodadas e difusão. A versão normativa é o PDF da especificação no bundle.
1 Origem e classificação Base Rijndael · distinção em relação ao AES segundo FIPS 197 ▾
XAES-512 se baseia no Protectstar Extended AES, lançado pela primeira vez em 2007. Ele usa uma matriz de estado 4×16 (512 bits) em vez da matriz 4×4 (128 bits) usada pelo AES padrão, e mantém inalterados AddRoundKey, MixColumns e a S-box SubBytes de Rijndael; os deslocamentos ShiftRows, o número de rodadas e a expansão de chave são estendidos.
Hoje, o nome significa “Extended Algorithm, Enhanced Security.” XAES-512 não é AES conforme definido pelo FIPS 197 e não é um substituto para ele.
2 Construção: criptografia autenticada (AEAD) CTR · HMAC-SHA-512 · Encrypt-then-MAC ▾
XAES-512 fornece uma única construção autenticada — não vários modos de operação livremente selecionáveis. A confidencialidade é fornecida pelo modo Counter (CTR); integridade e autenticidade são fornecidas por HMAC-SHA-512 seguindo o esquema Encrypt-then-MAC (composição genérica segundo Bellare–Namprempre). A tag de autenticação é verificada antes de cada descriptografia.
O formato da mensagem é definido como Wire Format v1 (perfil 0x02). Os dados associados (Associated Data) são incluídos na autenticação.
3 Derivação de chaves (KDF) PBKDF2-HMAC-SHA-512 · HKDF · salt por mensagem ▾
Uma chave é derivada da senha usando PBKDF2-HMAC-SHA-512 — com um salt aleatório para cada mensagem e 220.000 iterações (perfil 0x02). Em seguida, HKDF-SHA-512 separa as chaves para criptografia e autenticação. As senhas são codificadas em UTF-8 e normalizadas em Unicode NFC para que entradas idênticas produzam a mesma chave em diferentes plataformas.
O campo de iterações transmitido no cabeçalho é limitado (limite de implementação), de modo que uma mensagem não consiga forçar computação excessiva antes da verificação da tag.
4 Número total de rodadas Derivação das 24 rodadas ▾
O número de rodadas segue a derivação baseada em Rijndael descrita no documento: o maior número de palavras entre o tamanho do bloco e o tamanho da chave é decisivo. Para um bloco de 512 bits, isso corresponde a 16 palavras → 22 rodadas; o perfil 0x02 acrescenta mais duas rodadas em conexão com a estrutura ShiftRows estendida, resultando em 24 rodadas no total.
5 Expansão de chave Processo KeyExpansion estendido ▾
Processo KeyExpansion estendido baseado na especificação Rijndael:
KeyExpansion(byte Key[4*Nk], word W[Nb*(Nr+1)])
{
for (i = 0; i < Nk; i++)
W[i] = (Key[4*i], Key[4*i+1], Key[4*i+2], Key[4*i+3]);
for (i = Nk; i < Nb*(Nr+1); i++) {
temp = W[i-1];
if (i % Nk == 0 || (i % Nk == 4 && Nk > 6))
temp = SubByte(RotByte(temp)) ^ Rcon[i / Nk];
else if ((i % Nk == 8 || i % Nk == 12) && Nk > 6)
temp = SubByte(temp);
W[i] = W[i-Nk] ^ temp;
}
} 6 ShiftRows e difusão Deslocamentos {0,1,4,5} · diffusion_check.py ▾
Com os deslocamentos padrão {0,1,2,3}, a variante de 512 bits atinge difusão completa na medição estrutural de difusão incluída somente após 6 rodadas. Os deslocamentos selecionados {0,1,4,5} a atingem nessa medição após 4 rodadas.
A afirmação sobre difusão pode ser reproduzida usando a ferramenta diffusion_check.py no bundle. O arquivo core-kats.json contém testes adicionais de resposta conhecida para o core cipher.
Referências. FIPS 197 (AES) · FIPS 180-4 (SHA) · FIPS 198-1 / RFC 2104 (HMAC) · RFC 8018 (PBKDF2) · RFC 5869 (HKDF) · NIST SP 800-38A (modos de operação) · Bellare–Namprempre 2000 (criptografia autenticada) · Daemen–Rijmen, “AES Proposal: Rijndael” · OWASP Password Storage Cheat Sheet. O PDF da especificação contém as referências completas.
O que o XAES-512 não é — pelo menos ainda não.
Uma classificação honesta de um rascunho de revisão pública inclui declarar claramente suas limitações.
- Experimental e em revisão pública. Uma criptoanálise independente completa do core cipher ainda está pendente. A publicação tem exatamente o objetivo de permitir essa revisão.
- Não é AES segundo FIPS 197. XAES-512 não é padronizado no FIPS 197, não foi validado por CAVP/FIPS e não é interoperável com AES-128/192/256.
- Implementação de referência informativa. Uma implementação de referência em Java está disponível atualmente; uma segunda implementação independente, incluindo uma em Rust, está planejada.
- Não reforçado contra ataques de canal lateral. A implementação de referência em Java é um artefato de referência rastreável, não uma implementação constant-time para produção.
- Formato congelado. Wire Format v1 / perfil 0x02 é fixo; perfis futuros, por exemplo com Argon2id, são planejados separadamente.
- Não é um substituto de produção durante a revisão. Algoritmos estabelecidos e padronizados continuam sendo a escolha correta para sistemas de produção enquanto a revisão estiver em andamento.
O bundle completo de revisão pública.
O bundle ZIP é o artefato oficial: especificação, implementação de referência, testes de resposta conhecida, ferramentas e documentos de governança em um único pacote. Os PDFs são downloads adicionais de conveniência.
Bundle de revisão pública XAES-512
Protectstar-XAES-512-spec-v2.0-rev4.2-2026-06-03.pdf PDF Implementação de referência (informativa)
Protectstar-XAES-512-reference-implementation-v2.0-rev4.2-2026-06-03.pdf TXT Build Manifest & SHA-256
BUILD-MANIFEST-rev4.2.txt
Os documentos técnicos estão em inglês. Após baixar, verifique o pacote com sha256sum em relação ao valor mostrado acima; dentro do bundle extraído, SHA256SUMS cobre cada arquivo individual. A versão histórica 1.0 de 2007 continua disponível como versão arquivada.


