Non uno standard.Aperto alla revisione.
XAES-512 è l’evoluzione di Protectstar Extended AES, pubblicato per la prima volta nel 2007 — un design derivato da Rijndael con blocco a 512 bit, 24 round e un moderno involucro AEAD. Pubblicato affinché possa essere esaminato in modo indipendente.
Una bozza di revisione — non un sostituto di AES approvato per l’uso in produzione.
XAES-512 non è un’implementazione AES secondo FIPS 197 e non è un sostituto drop-in di AES-128/192/256. La versione 2.0 rev4.2 è pubblicata come bozza aperta alla revisione — per crittoanalisi indipendente, revisione dell’implementazione e feedback della comunità, non come algoritmo approvato per l’uso in produzione.
Quattro numeri che descrivono il design.
XAES-512 può essere riassunto in pochi indicatori chiave — ciascuno con un chiaro significato tecnico, senza alcuna affermazione di superiorità.
In che cosa differiscono gli algoritmi.
AES standard, come definito in FIPS 197, è eccellente e rimane il riferimento. XAES-512 è un design indipendente, derivato da Rijndael, con un blocco più grande — non un sostituto, ma una proposta pubblicata apertamente per la revisione.
* Nella misurazione strutturale della diffusione inclusa, gli offset ShiftRows {0,1,4,5} raggiungono la diffusione completa dopo 4 round; lo schema ingenuo {0,1,2,3} richiede 6 round. In questa misurazione, AES standard raggiunge la diffusione completa già dopo 2 round nella sua matrice 4×4 più piccola. L’affermazione sulla diffusione può essere riprodotta con diffusion_check.py; i core KAT verificano inoltre la corretta implementazione del core cipher.
Un blocco più grande per passaggio.
Ogni cella è un byte. La matrice più grande elabora più dati per blocco — ed espande lo stato interno miscelato da ogni round.
24 round.
XAES-512 utilizza 24 round su una matrice di stato 4×16. I round interni seguono il principio Rijndael di AddRoundKey, SubBytes, ShiftRows e MixColumns; la struttura esatta dei round è definita nel PDF della specifica.
Tre proprietà descritte in modo oggettivo.
Cifratura autenticata
XAES-512 è una costruzione AEAD basata sul principio Encrypt-then-MAC: CTR per la riservatezza, HMAC-SHA-512 per integrità e autenticità. I messaggi manomessi vengono rilevati prima della decifratura.
Derivazione delle chiavi standardizzata
Le chiavi vengono derivate dalle password usando PBKDF2-HMAC-SHA-512 con un salt casuale per messaggio, seguito da HKDF-SHA-512 per la separazione delle chiavi. Il profilo 0x02 usa 220.000 iterazioni PBKDF2; le password sono codificate in UTF-8 e normalizzate NFC.
Aperto e riproducibile
Nessuna sicurezza basata sull’oscurità. Specifica, implementazione di riferimento, known-answer test e strumenti sono pubblicati come bundle Apache-2.0 — così chiunque può riprodurre e revisionare il design.
La specifica in sintesi.
Costruzione, derivazione delle chiavi, round e diffusione. La versione normativa è il PDF della specifica nel bundle.
1 Origine e classificazione Base Rijndael · distinzione da AES secondo FIPS 197 ▾
XAES-512 si basa su Protectstar Extended AES, pubblicato per la prima volta nel 2007. Usa una matrice di stato 4×16 (512 bit) invece della matrice 4×4 (128 bit) usata da AES standard e mantiene invariati AddRoundKey, MixColumns e la S-box SubBytes di Rijndael; gli offset ShiftRows, il numero di round e l’espansione della chiave sono estesi.
Oggi il nome sta per “Extended Algorithm, Enhanced Security.” XAES-512 non è AES come definito da FIPS 197 e non ne è un sostituto.
2 Costruzione: cifratura autenticata (AEAD) CTR · HMAC-SHA-512 · Encrypt-then-MAC ▾
XAES-512 fornisce un’unica costruzione autenticata — non diverse modalità operative liberamente selezionabili. La riservatezza è fornita dalla modalità Counter (CTR); integrità e autenticità sono fornite da HMAC-SHA-512 secondo lo schema Encrypt-then-MAC (composizione generica secondo Bellare–Namprempre). Il tag di autenticazione viene verificato prima di ogni decifratura.
Il formato del messaggio è definito come Wire Format v1 (profilo 0x02). I dati associati (Associated Data) sono inclusi nell’autenticazione.
3 Derivazione delle chiavi (KDF) PBKDF2-HMAC-SHA-512 · HKDF · salt per messaggio ▾
Una chiave viene derivata dalla password usando PBKDF2-HMAC-SHA-512 — con un salt casuale per ogni messaggio e 220.000 iterazioni (profilo 0x02). HKDF-SHA-512 separa poi le chiavi per cifratura e autenticazione. Le password sono codificate in UTF-8 e normalizzate Unicode NFC, in modo che input identici producano la stessa chiave su piattaforme diverse.
Il campo delle iterazioni trasmesso nell’header è limitato superiormente (limite di implementazione), così un messaggio non può imporre un carico di calcolo eccessivo prima della verifica del tag.
4 Numero totale di round Derivazione dei 24 round ▾
Il numero di round segue la derivazione basata su Rijndael descritta nel documento: è decisivo il numero di parole più grande tra dimensione del blocco e dimensione della chiave. Per un blocco a 512 bit, questo valore è 16 parole → 22 round; il profilo 0x02 aggiunge due round ulteriori in relazione alla struttura ShiftRows estesa, per un totale di 24 round.
5 Espansione della chiave Processo KeyExpansion esteso ▾
Processo KeyExpansion esteso basato sulla specifica 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 diffusione Offset {0,1,4,5} · diffusion_check.py ▾
Con gli offset standard {0,1,2,3}, la variante a 512 bit raggiunge la diffusione completa nella misurazione strutturale inclusa solo dopo 6 round. Gli offset selezionati {0,1,4,5} la raggiungono in questa misurazione dopo 4 round.
L’affermazione sulla diffusione può essere riprodotta usando lo strumento diffusion_check.py nel bundle. Il file core-kats.json contiene ulteriori known-answer test per il core cipher.
Riferimenti. FIPS 197 (AES) · FIPS 180-4 (SHA) · FIPS 198-1 / RFC 2104 (HMAC) · RFC 8018 (PBKDF2) · RFC 5869 (HKDF) · NIST SP 800-38A (modalità operative) · Bellare–Namprempre 2000 (cifratura autenticata) · Daemen–Rijmen, “AES Proposal: Rijndael” · OWASP Password Storage Cheat Sheet. Il PDF della specifica contiene i riferimenti completi.
Che cosa XAES-512 non è — almeno non ancora.
Una classificazione onesta di una bozza di revisione pubblica richiede di dichiararne chiaramente i limiti.
- Sperimentale e in revisione pubblica. Una crittoanalisi indipendente completa del core cipher è ancora in sospeso. La pubblicazione è pensata proprio per rendere possibile tale revisione.
- Non è AES secondo FIPS 197. XAES-512 non è standardizzato in FIPS 197, non è validato CAVP/FIPS e non è interoperabile con AES-128/192/256.
- Implementazione di riferimento informativa. Attualmente è disponibile un’implementazione di riferimento in Java; è prevista una seconda implementazione indipendente, anche in Rust.
- Non rafforzato contro attacchi side-channel. L’implementazione di riferimento in Java è un artefatto di riferimento tracciabile, non un’implementazione constant-time per la produzione.
- Formato congelato. Wire Format v1 / profilo 0x02 è fisso; profili futuri, ad esempio con Argon2id, sono pianificati separatamente.
- Non un sostituto per la produzione durante la revisione. Gli algoritmi consolidati e standardizzati rimangono la scelta corretta per i sistemi di produzione mentre la revisione è in corso.
Il bundle completo per la revisione pubblica.
Il bundle ZIP è l’artefatto autorevole: specifica, implementazione di riferimento, known-answer test, strumenti e documenti di governance in un unico pacchetto. I PDF sono download aggiuntivi di comodo.
Bundle XAES-512 per revisione pubblica
Protectstar-XAES-512-spec-v2.0-rev4.2-2026-06-03.pdf PDF Implementazione di riferimento (informativa)
Protectstar-XAES-512-reference-implementation-v2.0-rev4.2-2026-06-03.pdf TXT Build Manifest & SHA-256
BUILD-MANIFEST-rev4.2.txt
I documenti tecnici sono in inglese. Dopo il download, verifica il pacchetto con sha256sum confrontandolo con il valore mostrato sopra; all’interno del bundle estratto, SHA256SUMS copre ogni singolo file. La versione storica 1.0 del 2007 rimane disponibile come versione archiviata.


