Not a standard.Open for review.
XAES-512 is the evolution of Protectstar Extended AES, first released in 2007 — a Rijndael-derived design with a 512-bit block, 24 rounds, and a modern AEAD envelope. Published so it can be independently reviewed.
A review draft — not an AES replacement approved for production use.
XAES-512 is not a FIPS 197 AES implementation and is not a drop-in replacement for AES-128/192/256. Version 2.0 rev4.2 is published as an open review draft — for independent cryptanalysis, implementation review, and community feedback, not as an algorithm approved for production use.
Four numbers that describe the design.
XAES-512 can be reduced to a few key figures — each with clear technical meaning, without any claim of superiority.
How the algorithms differ.
Standard AES as defined in FIPS 197 is excellent and remains the reference. XAES-512 is an independent, Rijndael-derived design with a larger block — not a replacement, but a proposal published openly for review.
* In the included structural diffusion measurement, the ShiftRows offsets {0,1,4,5} reach full diffusion after 4 rounds; the naive pattern {0,1,2,3} requires 6 rounds. In this measurement, standard AES reaches full diffusion after only 2 rounds in its smaller 4×4 matrix. The diffusion statement can be reproduced with diffusion_check.py; the core KATs additionally verify the correct implementation of the core cipher.
A larger block per step.
Each cell is one byte. The larger matrix processes more data per block — and expands the internal state mixed by each round.
24 rounds.
XAES-512 uses 24 rounds on a 4×16 state matrix. The inner rounds follow the Rijndael principle of AddRoundKey, SubBytes, ShiftRows, and MixColumns; the exact round structure is defined in the specification PDF.
Three properties, described factually.
Authenticated encryption
XAES-512 is an AEAD construction based on the Encrypt-then-MAC principle: CTR for confidentiality, HMAC-SHA-512 for integrity and authenticity. Tampered messages are detected before decryption.
Standardized key derivation
Keys are derived from passwords using PBKDF2-HMAC-SHA-512 with a random salt per message, followed by HKDF-SHA-512 for key separation. Profile 0x02 uses 220,000 PBKDF2 iterations; passwords are UTF-8 encoded and NFC-normalized.
Open & reproducible
No security through obscurity. The specification, reference implementation, known-answer tests, and tools are published as an Apache-2.0 bundle — so anyone can reproduce and review the design.
The specification at a glance.
Construction, key derivation, rounds, and diffusion. The normative version is the specification PDF in the bundle.
1 Origin & classification Rijndael basis · distinction from FIPS 197 AES ▾
XAES-512 builds on Protectstar Extended AES, first released in 2007. It uses a 4×16 state matrix (512 bits) instead of the 4×4 matrix (128 bits) used by standard AES, and retains Rijndael’s AddRoundKey, MixColumns, and SubBytes S-box unchanged; the ShiftRows offsets, number of rounds, and key expansion are extended.
Today, the name stands for “Extended Algorithm, Enhanced Security.” XAES-512 is not AES as defined by FIPS 197 and is not a replacement for it.
2 Construction: authenticated encryption (AEAD) CTR · HMAC-SHA-512 · Encrypt-then-MAC ▾
XAES-512 provides a single authenticated construction — not several freely selectable modes of operation. Confidentiality is provided by Counter mode (CTR); integrity and authenticity are provided by HMAC-SHA-512 following the Encrypt-then-MAC scheme (generic composition according to Bellare–Namprempre). The authentication tag is verified before every decryption.
The message format is defined as Wire Format v1 (Profile 0x02). Associated data is included in the authentication.
3 Key derivation (KDF) PBKDF2-HMAC-SHA-512 · HKDF · salt per message ▾
A key is derived from the password using PBKDF2-HMAC-SHA-512 — with a random salt for each message and 220,000 iterations (Profile 0x02). HKDF-SHA-512 then separates the keys for encryption and authentication. Passwords are UTF-8 encoded and Unicode NFC-normalized so that identical inputs produce the same key across platforms.
The iteration field transmitted in the header is capped (implementation limit) so that a message cannot force excessive computation before tag verification.
4 Total number of rounds Derivation of the 24 rounds ▾
The number of rounds follows the Rijndael-derived derivation described in the document: the larger word count from block size and key size is decisive. For a 512-bit block, this is 16 words → 22 rounds; Profile 0x02 adds two further rounds in connection with the extended ShiftRows structure, resulting in 24 rounds in total.
5 Key expansion Extended KeyExpansion process ▾
Extended KeyExpansion process based on the Rijndael specification:
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 & diffusion Offsets {0,1,4,5} · diffusion_check.py ▾
With the standard offsets {0,1,2,3}, the 512-bit variant reaches full diffusion in the included structural diffusion measurement only after 6 rounds. The selected offsets {0,1,4,5} reach it in this measurement after 4 rounds.
The diffusion statement can be reproduced using the diffusion_check.py tool in the bundle. The core-kats.json file contains additional known-answer tests for the core cipher.
References. FIPS 197 (AES) · FIPS 180-4 (SHA) · FIPS 198-1 / RFC 2104 (HMAC) · RFC 8018 (PBKDF2) · RFC 5869 (HKDF) · NIST SP 800-38A (modes of operation) · Bellare–Namprempre 2000 (authenticated encryption) · Daemen–Rijmen, “AES Proposal: Rijndael” · OWASP Password Storage Cheat Sheet. The specification PDF contains the complete references.
What XAES-512 is not — at least not yet.
An honest classification of a public review draft includes clearly stating its limitations.
- Experimental and under public review. A completed independent cryptanalysis of the core cipher is still pending. The publication is intended precisely to enable that review.
- Not FIPS 197 AES. XAES-512 is not standardized in FIPS 197, has not been CAVP/FIPS validated, and is not interoperable with AES-128/192/256.
- Informative reference implementation. A Java reference implementation is currently available; an independent second implementation, including one in Rust, is planned.
- Not hardened against side-channel attacks. The Java reference implementation is a traceable reference artifact, not a constant-time production implementation.
- Frozen format. Wire Format v1 / Profile 0x02 is fixed; future profiles, for example with Argon2id, are planned separately.
- Not a production replacement during review. Established, standardized algorithms remain the right choice for production systems while the review is ongoing.
The complete public review bundle.
The ZIP bundle is the authoritative artifact: specification, reference implementation, known-answer tests, tools, and governance documents in one package. The PDFs are additional convenience downloads.
XAES-512 Public Review Bundle
Protectstar-XAES-512-spec-v2.0-rev4.2-2026-06-03.pdf PDF Reference implementation (informative)
Protectstar-XAES-512-reference-implementation-v2.0-rev4.2-2026-06-03.pdf TXT Build Manifest & SHA-256
BUILD-MANIFEST-rev4.2.txt
The technical documents are in English. After downloading, verify the package with sha256sum against the value shown above; inside the extracted bundle, SHA256SUMS covers every individual file. The historical version 1.0 from 2007 remains available as an archived version.


