AES-256 o OFB: scegliere una costruzione di cifratura VPN completa

AES-256 e OFB rispondono a domande diverse, ed è qui che le revisioni dei cifrari sbagliano quando li trattano come opzioni concorrenti. Uno nomina un cifrario a blocchi con una dimensione di chiave; l’altro descrive come un cifrario a blocchi diventa un flusso per un messaggio più lungo. Un manuale per scegliere la protezione deve guardare l’intera costruzione, compreso come il destinatario rileva un pacchetto modificato.

Nominate le quattro parti della costruzione

Ogni revisione si riduce a quattro domande: quale primitiva e dimensione di chiave, come vengono elaborati i messaggi con essa, come il destinatario rifiuta una modifica non autorizzata e come il protocollo gestisce input, chiavi e loro durata. Un elenco di nomi familiari risponde solo alla prima. La seconda e la terza sono dove vivono le differenze reali, e la quarta è dove le implementazioni divergono in silenzio. Ponetele in quest’ordine e scrivete le risposte.

OFB compare tra i modi di riservatezza nella pubblicazione NIST sui modi dei cifrari a blocchi, e la riservatezza è tutto ciò che offre. Un protocollo che abbina un modo di cifratura a un MAC separato deve comporli correttamente, e il nome di un algoritmo non dimostra quella composizione. Per questo il nome del modo da solo non può risolvere una decisione di distribuzione.

La quarta domanda è quella che un operatore può davvero verificare sul sistema in esecuzione.

Preferite una costruzione autenticata

La cifratura autenticata fornisce riservatezza e integrità insieme, e le costruzioni AEAD proteggono anche i dati associati dalle modifiche senza cifrarli. È una proprietà della protezione dei pacchetti e non ha relazione con il fatto che una persona abbia effettuato l’accesso.

La Guida Netgate alle impostazioni crittografiche di OpenVPN indica opzioni AEAD, tra cui AES-GCM, per il canale dati, e questo è il tipo di politica supportata da seguire. Usate le scelte supportate dalla versione installata e dai client peer, invece di copiare una classificazione storica dei modi in una nuova distribuzione. La compatibilità legacy, i backend crittografici e il supporto offload limitano ciò che è realmente disponibile.

Una costruzione supportata batte una composizione ingegnosa ogni volta.

Leggete il risultato negoziato, non l’offerta

Un cifrario che compare in un elenco accettato non dice nulla sulla sessione corrente. Leggete la protezione negoziata del canale dati dal client o dal gateway, poi confrontatela con la politica che volevate applicare. Una configurazione che elenca ancora un’opzione legacy per un peer vecchio è una decisione di compatibilità, non un’affermazione sulla sessione davanti a voi.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

Su un gateway l’output equivalente è l’associazione di sicurezza o i dettagli crittografici della connessione, a seconda della piattaforma. In entrambi i casi l’offerta e il risultato sono fatti diversi. Un elenco che include un’opzione legacy per un peer vecchio non significa che ogni sessione la usi, e la sessione che la usa è ciò che dovevate sapere.

Registrate entrambi i fatti insieme, con la data e la versione del client.

Misurate solo ciò che è confrontabile

Il throughput dipende dall’hardware degli estremi, dall’implementazione, dall’accelerazione, dalle dimensioni dei pacchetti e dalla configurazione scelta. Né la lunghezza della chiave né la parola OFB vi dicono quale distribuzione sarà più veloce. Per questo un benchmark di un altro sito è al massimo un indizio sull’hardware di qualcun altro. I vostri numeri partono dai vostri estremi.

Per un confronto autorizzato, mantenete costanti gli estremi, il carico di lavoro e la politica richiesta, e registrate la protezione negoziata insieme alle versioni dell’implementazione. Poi giudicate il risultato in base al fatto che l’applicazione abbia finito, quanto abbia perso e cosa stessero facendo gli estremi, invece di dedurre un costo crittografico da un singolo test di velocità. Un numero prodotto in altre condizioni è una storia, non una misura.

Se un peer vecchio non riesce a rispettare la politica, è una decisione di compatibilità del suo proprietario.

Tenete l’integrità fuori dallo scambio

Disattivare i controlli di integrità o accettare un server non verificato non è un’ottimizzazione delle prestazioni e non è una correzione di compatibilità. Cambia la proprietà di sicurezza per cui la costruzione è stata scelta. Lo stesso vale per ampliare l’elenco dei cifrari accettati finché un peer vecchio non si connette: la connessione riesce e la politica non esiste più.

Scrivete la costruzione accettata e il suo proprietario nel manuale, così che il prossimo cambiamento parta da una decisione e non da una preferenza.

Ciò che volete è una politica che entrambi gli estremi possano applicare. Discutere che un nome sia il più forte è un’altra conversazione, e di solito finisce senza decisione.