Perché una chiave Blowfish più lunga non ripara un blocco da 64 bit

Un profilo VPN offre Blowfish con una chiave da 448 bit, e qualcuno propone di usare la chiave più lunga per mantenere il cifrario. La lunghezza della chiave è reale, ma è il numero sbagliato da ottimizzare. Blowfish trasforma blocchi da 64 bit indipendentemente dalla lunghezza della chiave, ed è l'ampiezza del blocco a limitare quanto traffico una chiave può proteggere in sicurezza. Esegui i controlli seguenti in ordine e fermati al primo che scagiona il servizio, perché un passo successivo non può riparare uno precedente.

Controlla cosa negoziano davvero i peer

Leggi il cifrario del canale dati da entrambe le estremità, non dal profilo che intendevi distribuire. Una configurazione client può elencare più cifrari, e quello scelto è il risultato della negoziazione tra due implementazioni e le loro versioni. Aumenta la verbosità dei log su una connessione di prova e leggi la riga del canale dati, che indica il cifrario e la dimensione della chiave effettivamente inizializzati.

Se il cifrario negoziato è AES-GCM o ChaCha20-Poly1305, fermati qui. Quelle costruzioni usano un blocco da 128 bit e autenticano il payload, quindi l'argomento sulle collisioni a 64 bit qui sotto non vale per loro.

Separa la lunghezza della chiave dall'ampiezza del blocco

Blowfish accetta chiavi da 32 a 448 bit, e la documentazione dell'autore dell'algoritmo riporta i due numeri separatamente. La chiave è il segreto; il blocco è l'unità di trasformazione. Allungare il segreto rende più difficile indovinarlo e non cambia nulla nell'ampiezza del blocco che il cifrario elabora.

In modalità CBC il cifrario viene applicato a blocchi di ampiezza fissa, concatenati con il blocco di testo cifrato precedente e riempiti alla fine. Per Blowfish quell'ampiezza è 64 bit, ovvero otto byte. La key schedule può essere grande quanto vuoi; la catena avanza comunque di otto byte alla volta.

Per questo allungare la chiave non è una mitigazione. Affronta la forza bruta contro la chiave, mentre il rischio di collisione qui sotto è una proprietà dell'ampiezza del blocco e della modalità.

Applica l'aritmetica dei compleanni alla dimensione del blocco

Un blocco da 64 bit ha una scala di compleanno di circa 2^32 blocchi cifrati sotto una sola chiave prima che le collisioni diventino probabili. Ogni blocco porta otto byte, quindi la stessa scala equivale a circa 2^35 byte, ovvero 32 GiB di dati sotto un'unica chiave.

Considerala una scala, non una quota. Le collisioni sono probabilistiche, e se una rivela qualcosa dipende dalla modalità, dal modello di traffico e dalla capacità dell'attaccante di riconoscere o influenzare il testo in chiaro circostante. Il primo byte oltre 32 GiB non è un evento di decifratura, e i primi 32 GiB non sono certificati come sicuri.

I ricercatori di Sweet32 hanno dimostrato nel 2016 attacchi pratici contro cifrari a blocchi da 64 bit, incluso uno scenario OpenVPN, in condizioni che richiedevano osservazione e generazione di traffico. Le loro impostazioni predefinite e versioni software pubblicate sono contesto storico, non una descrizione della tua distribuzione.

Decidi se il riutilizzo di CBC conta qui

In CBC, un blocco di testo cifrato ripetuto significa che i due blocchi di testo in chiaro differiscono per una relazione nota, perché l'XOR di concatenamento si annulla. Un attaccante che può osservare il testo cifrato e conosce o può influenzare uno dei testi in chiaro può recuperare informazioni sull'altro. La chiave Blowfish non serve mai per questo.

Le domande rilevanti sono quindi per quanto tempo una chiave resta in servizio, quanto traffico passa sotto di essa e se qualcuno può osservare e guidare quel traffico. Il rinnovo delle chiavi riduce il numero di blocchi per chiave, ma un intervallo di tempo non è un limite in byte: un tunnel occupato può spostare molti più dati di uno inattivo nella stessa ora. Se mantieni un cifrario legacy, ricava il limite dalla costruzione e dal volume effettivo, non da un numero tondo.

Se il volume misurato per chiave resta molto sotto la scala di compleanno, l'esposizione è minore. Non è comunque zero ed è ancora un motivo per pianificare una migrazione invece di smettere di preoccuparsi.

Sostituisci il cifrario, non la chiave

Sposta il servizio su un cifrario AEAD supportato e conferma che entrambi i peer, le loro versioni e i loro backend crittografici possano negoziarlo. Allungare la chiave Blowfish non cambia nulla che conti, e indovinare una nuova direttiva su un client è il modo in cui un tunnel funzionante diventa guasto. Prova la modifica su un client e un server prima di toccare il resto della flotta. Mantieni il vecchio profilo disponibile per il rollback finché il nuovo cifrario non ha superato un ciclo di connessione completo.

Mantieni la verifica dei certificati e l'autenticazione degli account durante la modifica. Rispondono a domande diverse: un accesso riuscito non può allargare un blocco, e un cifrario dati migliore non giustifica fidarsi del server sbagliato.

Chiudi il controllo rileggendo il cifrario negoziato su una nuova connessione e confermando poi che il vecchio cifrario non è più accettato. Se un peer lo offre ancora, la migrazione non è finita, qualunque cosa dica il profilo dall'altra parte.