AES-256 non salva un PDF se la chiave nasce dall’orologio

Puoi scegliere AES-256, imporre una password lunga, mettere il PDF dietro un portale autenticato e avere comunque un documento la cui chiave si può indovinare. Non perché qualcuno abbia trovato una scorciatoia matematica per rompere AES. Perché il software che ha preparato quella chiave ha usato un generatore prevedibile. È una differenza enorme, e racconta molto più della sicurezza dei PDF.

La ricerca pubblicata da Rick de Jager per V12 il 27 ottobre 2026 prende un caso apparentemente rassicurante, la cifratura AES-256 dei documenti, e ne segue il percorso fino alle righe di codice che producono i byte segreti. In alcune implementazioni la distanza tra i 256 bit dichiarati e la casualità effettiva è impressionante. Ma il punto che mi interessa non è la solita classifica di software vulnerabili: è il modo in cui un requisito di sicurezza si perde attraversando una dipendenza.

Il nome dell’algoritmo è solo l’ultimo pezzo del contratto

Quando un PDF usa la protezione AES-256, normalmente non cifra le pagine direttamente con la password digitata dall’utente. Genera una file key casuale di 32 byte, cifra i contenuti con quella chiave e conserva nel documento il materiale necessario a recuperarla attraverso la password. La password protegge quindi l’accesso alla chiave del file; non sostituisce la necessità che quella chiave sia imprevedibile.

Se la file key nasce da una sorgente casuale robusta, l’architettura può offrire una protezione solida. Se invece deriva da un numero piccolo di stati riproducibili, la password può anche essere eccellente: chi possiede il PDF può tentare direttamente le poche chiavi candidate, aggirando il lavoro previsto per indovinare la password. La cifratura continua a funzionare esattamente come progettato. È il segreto consegnato alla cifratura a non essere più un segreto.

Una funzione crittografica corretta non rende sicuro un sistema che le passa una chiave prevedibile.

MuPDF: 256 bit di lunghezza, nove bit di entropia effettiva

V12 documenta un problema preciso nelle versioni di MuPDF precedenti alla 1.28.5. Nel percorso analizzato, il generatore della famiglia drand48 viene inizializzato con il tempo corrente espresso in secondi. Non è soltanto il timestamp a essere prevedibile: il modo in cui il codice estrae ogni byte fa sì che i bit più alti dello stato non possano influenzare l’output utilizzato.

La conseguenza, ricostruita dall’analisi del generatore, è che per quel percorso contano soltanto nove bit dello stato iniziale. Nove bit significano 512 sequenze possibili. Due timestamp separati da 512 secondi producono lo stesso flusso di byte. Una chiave formalmente lunga 256 bit viene quindi scelta da un insieme minuscolo: non è corretto chiamarla una chiave AES a nove bit, ma è corretto dire che ha, in quel caso, soltanto nove bit di entropia effettiva.

I ricercatori riferiscono di aver recuperato la file key di un documento di prova verificando le 512 possibilità in circa 11 millisecondi con un’implementazione non ottimizzata. Quel numero descrive il loro test, non un tempo universale garantito per qualunque PDF. Il risultato tecnico importante è lo spazio di ricerca ridotto, non il cronometro.

Il dettaglio del campo /ID, generato dalla stessa sorgente e presente in chiaro nel PDF, aiuta anche a capire perché una scelta interna apparentemente innocua possa lasciare indizi verificabili nel formato finale. È proprio qui che una revisione concentrata sulla sola chiamata ad AES non avrebbe visto nulla.

Foxit, OpenPDF e iText: stesso principio, prove da distinguere

V12 esamina anche Foxit PDF Reader 2026.1.3.36551, per il quale descrive una derivazione della chiave basata su timestamp e altri valori che, nell’ambiente analizzato, risultano prevedibili. La ricerca presenta un recupero pratico delle chiavi per i casi testati. Non significa che ogni versione di Foxit o ogni PDF creato con Foxit condivida necessariamente lo stesso difetto.

Per OpenPDF 3.0.5 e iText 9.7.1 viene descritto invece un generatore ARC4 inizializzato con il tempo in millisecondi e informazioni sulla memoria disponibile nella JVM. Sono sorgenti inadatte a sostituire un generatore crittograficamente sicuro. Qui però la variabilità dello stato è maggiore e le condizioni concrete contano: sarebbe scorretto trasformare la scoperta di un pattern debole nell’affermazione che qualunque documento di quelle librerie si apre in pochi millisecondi.

Questa distinzione è essenziale. MuPDF ha un risultato quantitativo molto netto nel percorso studiato; per gli altri prodotti il rapporto presenta evidenze e limiti differenti. Un articolo serio non appiattisce tutto in un titolo che fa sembrare violabile ogni PDF AES-256 del pianeta.

La libreria che genera il PDF fa parte della tua superficie d’attacco

In un’applicazione web, la generazione dei documenti spesso sembra una funzione accessoria. Un gestionale prepara una fattura, un portale crea un cedolino, un e-commerce allega un documento riservato, una procedura Laravel invoca una libreria o un servizio esterno. Nella lista dei requisiti compare “PDF protetto con AES-256” e il team considera chiusa la questione. Ma chi ha controllato da dove arrivano i 32 byte della chiave?

Il confine di fiducia attraversa più livelli: il codice applicativo, il wrapper, la libreria PDF, la versione realmente incorporata nell’artefatto, il generatore casuale e infine il file distribuito. Se uno di questi livelli non rispetta il contratto di sicurezza, l’etichetta scelta a livello applicativo non lo ripara.

È un problema simile a quello che ho affrontato nell’analisi sulle patch .NET e i runtime incorporati nelle applicazioni: aggiornare il componente visibile non garantisce che il processo in produzione stia eseguendo il componente corretto. Per una libreria PDF vale lo stesso principio. Devi identificare la versione effettiva usata per scrivere il documento, non soltanto il nome del pacchetto dichiarato nel progetto.

Tre verifiche che valgono più di una checkbox

• Inventario reale: quale servizio genera i PDF cifrati, con quale libreria, wrapper e versione embedded? Distingui lettura, modifica e creazione di nuovi file.
• Proprietà verificabili: due processi indipendenti, avviati nello stesso intervallo, producono file key e campi crittografici differenti? Il test va costruito sul formato e sul runtime effettivi, non sulla presenza della stringa AES-256.
• Tracciabilità: riesci a collegare una versione vulnerabile ai documenti che ha prodotto, alle date e ai destinatari? Senza questa relazione, la patch risolve il futuro ma non ti dice cosa fare con il passato.

Una replica tecnica indipendente pubblicata il 30 ottobre 2026 ha verificato su PyMuPDF 1.28.2 che processi distinti avviati nello stesso secondo producevano campi crittografici identici nei test descritti, mentre la versione aggiornata no. Non è una certificazione universale di tutti i binding, ma mostra quanto possa essere utile un test di proprietà mirato, invece di limitarsi a controllare che l’API accetti il parametro di cifratura.

La patch corregge le nuove chiavi. Non riscrive i PDF già distribuiti

Le note ufficiali di MuPDF documentano nella versione 1.28.5 del 25 settembre 2026 la sostituzione del generatore con una sorgente crittografica basata su ChaCha20 (bug 709668). Il changelog di PyMuPDF 2.0 conferma l’uso di MuPDF 1.28.5. Sono due informazioni concrete, ma vanno lette con precisione: bisogna verificare la versione effettiva della libreria incorporata, e la correzione riguarda la generazione di nuove chiavi.

Un PDF già cifrato con una chiave prevedibile conserva quella chiave finché non viene realmente ricifrato. Installare la libreria aggiornata non modifica i byte dei documenti archiviati, inviati per email o già scaricati. Nemmeno un semplice salvataggio che preserva i campi di cifratura equivale necessariamente a generare una chiave nuova.

Per i documenti sensibili la risposta operativa richiede una valutazione del rischio: individuare quali file sono stati generati dal percorso vulnerabile, stabilire chi potrebbe possederne una copia, ricifrare gli originali ancora controllati con nuove chiavi e considerare la riemissione dove appropriato. Le copie già distribuite non possono essere cancellate o rese sicure retroattivamente da una patch sul server.

Non è diverso dal ragionare sul confine tra gestione delle chiavi e protezione effettiva dei dati: sapere che una chiave esiste in un luogo controllato non basta. Bisogna capire quando è stata creata, da chi viene usata e dove il contenuto torna leggibile.

Il controllo che manca non è un algoritmo più grande

La tentazione, dopo una notizia del genere, è cercare una nuova etichetta: AES più grande, password più lunga, un altro formato, un altro vendor. Ma il caso MuPDF dimostra il contrario. Il requisito corretto era già noto: generare chiavi con casualità crittograficamente sicura. Il problema è stato verificare che quel requisito sopravvivesse a tutte le implementazioni intermedie.

Per chi sviluppa software il lavoro non finisce con la scelta della tecnologia. Comincia con le domande che la tecnologia non può risolvere da sola: quale codice gira davvero, quali proprietà sono state testate, quali dati sono già stati prodotti e come si interviene se il contratto si rompe.

AES-256 non è stato sconfitto. È stata sconfitta, in alcuni percorsi documentati, l’assunzione che una chiave lunga sia automaticamente una chiave imprevedibile. Ed è una lezione che vale molto oltre i PDF.