Nuovo attacco contro RSA forgia firme senza recuperare la chiave privata
I ricercatori su RSA hanno completato una falsificazione di firma a 1024 bit usando 1.380 anni-core di CPU, senza fattorizzare il modulo pubblico né recuperare la relativa chiave privata.
Il risultato offre al nuovo attacco contro RSA un titolo d'effetto, ma l'algoritmo alla base risale al 2007. Il vero progresso consiste in un'implementazione che ha portato il metodo teorico fino a un calcolo su scala completa.
La distinzione è importante perché l'attacco non compromette ogni implementazione di RSA. Prende di mira sistemi che forniscono temporaneamente accesso a operazioni RSA raw e senza padding. Le firme moderne che usano una codifica standardizzata restano al di fuori del modello d'attacco dimostrato.
La valutazione dell'attacco di Bruce Schneier coglie il punto centrale. Si tratta di un risultato crittanalitico reale, ma non di una tecnica universale per estrarre chiavi private RSA.
Cosa è realmente cambiato nel nuovo attacco contro RSA
I ricercatori hanno trasformato un algoritmo del 2007 poco considerato in una falsificazione di firma a 1024 bit completata contro un obiettivo di firma reale.
Laura Shea, Miro Haller, Adam Suhl, Nadia Heninger ed Emmanuel Thomé hanno implementato l'attacco attraverso una collaborazione che ha coinvolto UC San Diego e Inria. Il loro calcolo a 1024 bit si è concluso il 31 agosto 2026.
Il team ha pubblicato il proprio paper e il codice di supporto a settembre. I materiali pubblici descrivono il lavoro come una falsificazione di firma eseguita in un tempo prossimo allo special number field sieve.
Questo nome si riferisce alle prestazioni asintotiche dell'attacco. Il number field sieve è una famiglia di algoritmi per calcoli difficili di teoria dei numeri, compresa la fattorizzazione di grandi interi.
Il general number field sieve, o GNFS, è il più veloce metodo classico noto per fattorizzare moduli RSA ordinari. Lo special number field sieve, o SNFS, offre prestazioni migliori quando un problema sottostante presenta una struttura algebrica sfruttabile.
La nuova implementazione sposta di fatto una parte dell'attacco nella categoria più veloce. Lo fa senza trasformare la crittanalisi di RSA in un problema facile o risolvibile in tempo polinomiale.
I ricercatori riferiscono che il calcolo ha consumato 1.380 anni-core di CPU. L'elaborazione parallela ha ridotto quel lavoro totale a diversi mesi di tempo effettivo su un cluster di calcolo accademico.
Resta un'impresa considerevole. Tuttavia, il team stima che fattorizzare lo stesso modulo a 1024 bit richiederebbe tra 500.000 e un milione di anni-core di CPU.
Queste stime non sono direttamente traducibili in un costo finanziario universale. Hardware, software, memoria, rete e scelte d'implementazione incidono tutti sulle spese operative reali.
Stabiliscono comunque il risultato tecnico centrale. Nelle condizioni oracle richieste, falsificare firme RSA può richiedere molta meno potenza di calcolo rispetto alla fattorizzazione del modulo associato.
Un oracle è un sistema che esegue un'operazione crittografica su input scelti dall'attaccante e restituisce il risultato. In questo caso, l'attaccante necessita di accesso temporaneo a operazioni di firma o decrittazione RSA raw.
L'accesso non deve restare disponibile per sempre. Dopo aver completato un'ampia precomputazione legata alla chiave pubblica, l'attaccante ottiene la capacità offline di produrre ulteriori output validi.
Questa persistenza rende il risultato più importante di un normale abuso di un servizio di firma. L'attaccante può conservare la capacità di falsificazione dopo aver perso accesso all'oracle originale.
La spiegazione dei ricercatori afferma che questa capacità assomiglia, nei suoi effetti pratici, al furto della chiave segreta. Non significa che i fattori privati effettivi siano stati recuperati.
I ricercatori hanno inoltre pubblicato la loro implementazione e i dati intermedi. Questa trasparenza consente ad altri crittografi di riprodurre le ipotesi, esaminare le decisioni ingegneristiche e testare le contromisure proposte.
Il calcolo completato è quindi l'evento di rilievo. La matematica che lo ha reso possibile è pubblica da quasi 19 anni.
Perché un algoritmo del 2007 conta oggi
L'implementazione modifica le stime di sicurezza di RSA in uno specifico modello d'attacco, anche se non introduce una nuova scorciatoia matematica.
Antoine Joux, David Naccache ed Emmanuel Thomé hanno descritto la tecnica sottostante nel loro paper del 2007. Hanno studiato in quali casi il calcolo di determinate radici modulo un numero RSA diventa più semplice della fattorizzazione di quel numero.
In termini semplificati, RSA applica l'elevamento a potenza modulo un numero composto. Un'operazione privata calcola una radice che dovrebbe restare irrealizzabile senza conoscere la chiave segreta.
Il lavoro del 2007 ha mostrato che risposte selezionate da un oracle potevano rivelare struttura sufficiente per un attacco più rapido. I suoi autori hanno descritto risultati che andavano dalle falsificazioni selettive a capacità di falsificazione universale.
Quel risultato non ha mai implicato che gli attaccanti potessero osservare passivamente una normale chiave pubblica RSA e falsificare immediatamente delle firme. Richiedeva accesso ripetuto a operazioni con chiave privata accuratamente strutturate.
Fino al 2026, nessuno aveva dimostrato pubblicamente il processo completo alla scala di 1024 bit. I grandi calcoli crittanalitici richiedono più di un'espressione di complessità stampata in un paper.
I ricercatori devono costruire selezioni polinomiali adatte, raccogliere relazioni, elaborare enormi dataset, eseguire algebra lineare sparsa e completare la ricostruzione finale. Piccole inefficienze possono moltiplicarsi nell'arco di mesi di lavoro.
Il nuovo team ha collegato queste fasi e dimostrato il risultato contro un obiettivo a 1024 bit. Gran parte della sua implementazione si basa su CADO-NFS, una suite software consolidata per calcoli con number field sieve.
Questa differenza tra teoria e implementazione è centrale nel nuovo attacco contro RSA. L'algoritmo era noto, ma le sue costanti pratiche e i requisiti ingegneristici erano rimasti incerti.
Un calcolo completato trasforma queste incognite in prove. Mostra che il divario computazionale tra falsificazione e fattorizzazione non è soltanto una curiosità asintotica.
Per l'obiettivo dimostrato, i ricercatori stimano un costo dell'attacco vicino a 2^65 operazioni. Confrontano questa cifra con circa 2^80 operazioni necessarie per fattorizzare un modulo RSA comparabile a 1024 bit.
Per chiavi più grandi, stimano approssimativamente 2^90 operazioni contro RSA a 2048 bit e 2^119 contro RSA a 4096 bit nel modello oracle vulnerabile.
Questi attacchi più grandi non sono stati completati. Sono proiezioni derivate dall'algoritmo, dalle prestazioni misurate dell'implementazione e dal comportamento di scalabilità previsto.
Le proiezioni meritano attenzione perché la forza di sicurezza misura il lavoro previsto necessario per violare un sistema. NIST definisce una forza di sicurezza di S bit come approssimativamente 2^S operazioni di base.
Tuttavia, queste cifre si applicano alla costruzione esposta, non a ogni utilizzo di una chiave RSA. La codifica di un protocollo, i controlli di accesso, i limiti di frequenza e la durata della chiave restano parte della sua sicurezza effettiva.
Anche il confronto richiede contesto. Un calcolo di 2^90 è enormemente più difficile dell'esperimento completato a 1024 bit, anche se resta al di sotto del margine teorico desiderato.
I ricercatori affermano che richiederebbe circa 1.000 volte più lavoro di un calcolo da 2^80. Nessun team pubblico ha ancora completato il corrispondente compito di fattorizzazione a 1024 bit.
Il risultato mette quindi sotto pressione i modelli di sicurezza più dei sistemi di produzione attuali. I progettisti non possono più presumere che la fattorizzazione offra sempre la migliore stima dell'attacco per operazioni RSA raw.
Questa correzione è importante per moduli di sicurezza hardware, protocolli di firma cieca e interfacce specializzate. Questi sistemi talvolta espongono l'operazione privata RSA cercando al contempo di limitarne le autorizzazioni.
Se il protocollo circostante fornisce l'oracle necessario, una stima della lunghezza della chiave basata soltanto su GNFS può sovrastimare la sicurezza. L'implementazione offre ai progettisti un motivo concreto per rivedere tale analisi.
Il nuovo attacco contro RSA è falsificazione, non recupero della chiave
L'attacco compromette una capacità di firma in condizioni di input scelto, ma non ricava la chiave privata RSA da informazioni pubbliche.
Le chiavi RSA contengono un modulo e un esponente pubblici, oltre a valori privati derivati dai fattori primi segreti del modulo. Gli attacchi di fattorizzazione convenzionali cercano tali fattori.
Recuperarli fornisce all'attaccante la chiave privata effettiva. Tale chiave può supportare ogni operazione autorizzata dalla costruzione RSA interessata, soggetta ai dettagli del protocollo.
Questa tecnica di falsificazione delle firme segue un'altra strada. Usa le risposte di un oracle RSA raw per preparare dati che supportano successivi calcoli di radici.
L'attaccante parte da un accesso temporaneo a un dispositivo o protocollo che esegue operazioni con chiave privata senza padding. L'attaccante invia molti valori selezionati appositamente e registra le risposte.
La precomputazione cerca quindi relazioni algebriche mediante una variante del number field sieve. Una volta raccolte abbastanza relazioni, l'attaccante può combinarle per falsificare output scelti.
La maggior parte del costoso calcolo dipende dalla chiave pubblica. Dopo questa fase, produrre singole falsificazioni diventa considerevolmente meno oneroso.
Dal punto di vista del difensore, il risultato può assomigliare al furto della chiave privata. Una parte non autorizzata può generare firme che vengono verificate con la chiave pubblica autentica.
Tuttavia, meccanismo e portata restano differenti. Il modulo pubblico non è stato fattorizzato e l'esponente privato non è stato necessariamente ricostruito.
Questa distinzione influenza la risposta agli incidenti. Sostituire la chiave interessata blocca le verifiche future con quella chiave pubblica, come avverrebbe dopo una normale compromissione.
Influenza anche la valutazione della vulnerabilità. Un sistema privo dell'interfaccia di firma raw richiesta non diventa vulnerabile semplicemente perché utilizza un certificato RSA.
Definire il lavoro come una violazione delle “chiavi RSA” può confondere questi confini. Può far pensare a un attacco passivo che parte soltanto da un certificato o una chiave pubblica.
L'attacco dimostrato richiede di più. Necessita di una fonte interattiva di risultati RSA raw scelti e di un numero sufficiente di query prima che la fonte scompaia o la chiave venga ruotata.
Il paper completo dei ricercatori presenta il contributo come la falsificazione di firme in un tempo prossimo a SNFS. Questa formulazione identifica accuratamente sia il risultato sia il miglioramento della complessità.
Evita inoltre un altro equivoco comune. Subesponenziale non significa polinomiale, istantaneo o economico.
Gli algoritmi in tempo polinomiale scalano con una potenza fissa della dimensione del loro input. Gli algoritmi subesponenziali crescono più rapidamente di quelli polinomiali, pur più lentamente di quelli pienamente esponenziali.
Sia SNFS sia GNFS appartengono alla categoria subesponenziale. L'attacco è più rapido perché le sue costanti e la sua struttura sono più favorevoli, non perché elimina il calcolo difficile.
L'esperimento completato ha utilizzato CPU anziché GPU. I ricercatori affermano inoltre di non aver usato intelligenza artificiale per ottimizzare il proprio codice.
Ritengono che le GPU e ulteriore lavoro di implementazione possano migliorare le prestazioni. È una direzione di ricerca ragionevole, ma non è un risultato misurato da questo esperimento.
Le affermazioni su una drastica accelerazione tramite GPU restano quindi speculative. I carichi di lavoro del number field sieve comprendono diverse fasi e ciascuna risponde in modo diverso all'hardware specializzato.
Il benchmark dimostrato è di 1.380 anni-core di CPU nell'implementazione effettiva del team. Qualsiasi cifra futura inferiore dovrebbe derivare da codice riproducibile e misurazioni completate.
Questa è la tensione principale dell'articolo. Il lavoro rappresenta una rottura significativa rispetto alle ipotesi basate sulla fattorizzazione, ma non è un metodo generale per recuperare chiavi RSA.
L'esposizione reale è limitata ma non nulla
Le normali firme RSA con padding non sono il bersaglio dimostrato, mentre le interfacce di firma raw meritano una revisione immediata.
Le moderne firme RSA normalmente non applicano l'esponente privato direttamente a un messaggio senza restrizioni. Prima codificano un digest del messaggio usando uno schema di firma definito.
RSASSA-PSS aggiunge una formattazione casuale prima dell'operazione RSA. PKCS #1 v1.5 usa una codifica deterministica strutturata con identificatori e padding.
Queste codifiche impediscono a un attaccante di scegliere interi raw arbitrari da firmare. Tale restrizione blocca il comportamento da oracolo richiesto dalla nuova implementazione.
Il team di ricerca afferma che il proprio attacco non sembra realizzabile contro le comuni firme RSA che usano PSS o PKCS #1 v1.5. Schneier giunge alla stessa conclusione pratica.
Ciò significa che certificati convenzionali, firme di autenticazione TLS, software firmato e token non sono automaticamente esposti. Gli amministratori dovrebbero verificare l'algoritmo e l'interfaccia effettivi prima di trarre conclusioni.
La sola lunghezza della chiave non risponde alla questione della vulnerabilità. Una chiave da 2048 bit dietro un'API di firma raw ha un'esposizione diversa dalla stessa chiave limitata a firme PSS validate.
I candidati più evidenti per una revisione sono le interfacce dei moduli di sicurezza hardware che consentono operazioni raw con la chiave privata. Talvolta le applicazioni richiedono tale accesso per implementare protocolli personalizzati al di fuori del modulo.
Questa flessibilità può indebolire il confine che il modulo era destinato a fornire. La chiave privata non lascia mai il dispositivo, eppure l'operazione disponibile può diventare un oracolo di firma.
Le firme cieche richiedono un'analisi più approfondita perché il loro scopo comporta la firma di contenuti nascosti al firmatario. Un client trasforma il proprio messaggio, ottiene una firma e poi rimuove il fattore di accecamento.
Questo design supporta l'autenticazione che preserva la privacy e le applicazioni di denaro digitale. Crea inoltre un'interfaccia in cui il client influenza il valore elaborato dalla chiave privata.
I moderni protocolli RSA ciechi aggiungono requisiti di codifica e verifica. L'attuale standard sulle firme cieche usa la codifica RSA-PSS attorno al messaggio preparato dal client.
Tuttavia, il server di firma esegue comunque un'operazione privata RSA su un rappresentante accecato. Il nuovo articolo analizza come tali interfacce possano esporre l'oracolo raw necessario durante l'emissione.
Privacy Pass è un caso d'uso frequentemente citato. Consente a un client di ottenere token anonimi che i servizi possono verificare senza collegare l'emissione al successivo riscatto.
Apple e Cloudflare hanno usato tecnologie correlate a Privacy Pass in servizi per la privacy e sistemi di aggiramento delle challenge. Ciò non dimostra che ogni implementazione sia sfruttabile.
Un attacco riuscito contro un servizio attivo richiederebbe la costruzione corretta, una chiave pubblica stabile e un numero sufficiente di query all'oracolo accettate. I controlli operativi possono modificare il calcolo.
I ricercatori stimano che l'attacco a una chiave RSA cieca da 2048 bit richieda circa 2^43 query all'oracolo, oltre a un calcolo offline molto più ampio.
Quel numero di query supera gli otto trilioni. È enorme per un singolo utente, anche se grandi servizi distribuiti elaborano traffico su scale aggregate comparabili.
Il rate limiting può limitare le richieste legate a un singolo account, dispositivo, rete o credenziale. Il rilevamento degli abusi può anche identificare modelli di emissione insolitamente ripetitivi.
La rotazione delle chiavi riduce la finestra di raccolta disponibile. Se un servizio sostituisce la sua chiave RSA prima che un attaccante raccolga risposte sufficienti, le query precedenti non possono semplicemente essere trasferite alla nuova chiave.
Epochi di chiave brevi aumentano quindi i costi operativi per l'attaccante. Non modificano la matematica né sostituiscono completamente una difesa a livello di protocollo.
I ricercatori suggeriscono che le prove a conoscenza zero potrebbero offrire una risposta più solida nel medio termine. Tali prove possono vincolare gli input del client senza rivelare il messaggio nascosto.
Anche chiavi RSA più lunghe aumentano i costi dell'attacco, ma l'articolo mette in dubbio i loro margini di sicurezza con questo modello di oracolo. Gli autori stimano una robustezza inferiore a 128 bit persino a 4096 bit.
Ciò non significa che gli attaccanti possano ora falsificare firme da 4096 bit. La stima di 2^119 resta ben oltre il calcolo completato a 1024 bit.
Significa però che i progettisti di protocolli non dovrebbero considerare chiavi più grandi come l'unica risposta a lungo termine. Un'interfaccia vulnerabile può preservare lo stesso problema strutturale a un costo maggiore.
Per la maggior parte delle organizzazioni, la risposta corretta è un inventario anziché uno spegnimento d'emergenza. I team di sicurezza dovrebbero individuare le chiavi RSA e identificare ogni operazione consentita con la chiave privata.
Dovrebbero distinguere cifratura, firme convenzionali, firme cieche, emissione di certificati, firma di token e chiamate HSM personalizzate. Ogni percorso espone una superficie d'attacco diversa.
I team dovrebbero confermare che le applicazioni richiedano meccanismi di firma nominati anziché un'esponenziazione modulare generica. Dovrebbero inoltre rifiutare codifiche non valide prima di accettare oggetti firmati.
L'attuale guida NIST sulla gestione delle chiavi considera già l'RSA a 1024 bit obsoleto per i requisiti di protezione moderni. Questo esperimento aggiunge un ulteriore motivo per rimuovere le implementazioni ancora presenti.
Un servizio di firma raw a 1024 bit merita una correzione urgente. Un'implementazione PSS standard a 2048 bit non affronta la stessa scoperta immediata, anche se una pianificazione migratoria più ampia rimane importante.
Cosa dovrebbero osservare i difensori in seguito
I prossimi tre segnali sono la riproduzione indipendente, l'analisi specifica dei protocolli e cambiamenti misurabili nelle implementazioni reali.
In primo luogo, i crittografi dovrebbero riprodurre indipendentemente il calcolo a 1024 bit e riesaminare le stime di scalabilità dell'articolo. La riproduzione può verificare se il costo riportato includa ogni fase sostanziale.
Può anche rivelare colli di bottiglia nell'implementazione che rafforzano o indeboliscono le proiezioni. Un costo riproducibile inferiore aumenterebbe la preoccupazione per le interfacce di firma raw esposte.
Un costo sostanzialmente più elevato non eliminerebbe il risultato concettuale. Ridurrebbe la minaccia operativa e renderebbe meno urgenti le stime per chiavi più grandi.
In secondo luogo, i gruppi di standardizzazione e i progettisti di protocolli dovrebbero pubblicare analisi per le costruzioni RSA cieche. Affermazioni generiche sul “padding” sono insufficienti quando l'accecamento modifica ciò che il firmatario elabora.
La domanda importante è se un protocollo concreto fornisca agli attaccanti le risposte dell'oracolo presupposte dall'articolo. L'autenticazione delle query e la rotazione delle chiavi devono rientrare in questa valutazione.
Le implementazioni di Privacy Pass meritano particolare attenzione perché combinano obiettivi di privacy, emissione ripetuta di token e client ampiamente distribuiti. Revisioni pubbliche del design possono separare l'esposizione teorica dagli attacchi concretamente raggiungibili.
Una revisione del protocollo che richieda prove di input più robuste rafforzerebbe l'avvertimento dei ricercatori. Una prova convincente che le implementazioni comuni neghino l'oracolo richiesto restringerebbe la portata pratica del risultato.
In terzo luogo, i difensori dovrebbero osservare i fornitori di HSM e le librerie crittografiche. Documentazione, impostazioni predefinite delle API, regole di audit e avvisi di deprecazione mostrano come il settore interpreti la scoperta.
Un HSM può proteggere il materiale della chiave pur esponendo un'operazione pericolosa. I fornitori potrebbero limitare le chiamate RSA raw, aggiungere controlli sulle query o raccomandare interfacce specifiche per meccanismo.
Anche i manutentori delle librerie potrebbero rendere più restrittive le API di basso livello. Deprecare l'esponenziazione privata raw ridurrebbe la probabilità che gli sviluppatori costruiscano accidentalmente un oracolo di firma esposto.
Nessuno di questi segnali richiede di abbandonare immediatamente tutti i certificati RSA. L'attacco dimostrato non raggiunge le firme standardizzate con padding tramite osservazione passiva.
RSA affronta ancora un problema separato a lungo termine legato ai computer quantistici crittograficamente rilevanti. I programmi di migrazione post-quantistica offrono già alle organizzazioni l'opportunità di ridurre la dipendenza da algoritmi legacy.
NIST ha standardizzato i suoi primi algoritmi di firma post-quantistica nel 2024. La migrazione richiederà comunque anni perché certificati, hardware, protocolli e strumenti operativi devono cambiare insieme.
Il nuovo attacco sostiene la pianificazione della cripto-agilità, ossia sistemi capaci di sostituire gli algoritmi senza riprogettare un intero prodotto. Non giustifica però di saltare i test di compatibilità o modificare in emergenza sistemi non interessati.
I responsabili della sicurezza dovrebbero ora porsi quattro domande concrete. Qualche servizio usa ancora RSA a 1024 bit, espone operazioni raw con chiave privata, implementa RSA cieco oppure mantiene una chiave per periodi insolitamente lunghi?
Un “sì” dovrebbe attivare una revisione del protocollo, un'analisi dei log e un calendario di migrazione. Non dovrebbe attivare l'affermazione non supportata che la chiave privata sia già stata estratta.
The New Attack Against RSA è significativo perché sostituisce un vecchio avvertimento teorico con un calcolo completato. Il suo confine pratico è altrettanto importante.
Considerate il risultato come un test delle assunzioni crittografiche e della progettazione delle interfacce. Verificate quali operazioni espongono i vostri sistemi, quindi seguite le riproduzioni e le conclusioni specifiche dei protocolli prima di decidere la risposta.



