Svantaggi di AES-CTR?
Sulla carta, mi sembra * molto * buono:
- sicuro
- veloce (nei miei test è un po 'più lento di ECB (ma senza la maggior parte dei punti deboli, più su quello di seguito) ma più veloce di ogni altra alternativa che ho testato, che sono state
ECB, CTR, CBC, OFB, CFBscritte in ordine di prestazioni ( link al codice benchmark )) - semplice da capire
- non richiede il riempimento (che immagino riduca significativamente la possibilità di implementare il riempimento in modo insicuro)
- supportare la parallelizzazione (sia per la crittografia che per la decrittografia)
- supportare l'accesso casuale
.. l'unico svantaggio a cui riesco a pensare è che, poiché non richiede riempimento, le implementazioni in pratica probabilmente riveleranno la lunghezza esatta del messaggio , rispetto alla rivelazione della lunghezza del messaggio circa (ad esempio gli schemi imbottiti possono rivelare qualcosa di simile the message is within 15 bytes of this length, mentre non -schemi imbottiti possono rivelare the message is *exactly* this long), e se questo è un problema, non è che non possa essere mitigato semplicemente aggiungendo imbottitura comunque.
Immagino che mi manchi qualcosa, quindi ...
Quali sono gli svantaggi?
Risposte
Svantaggi:
Lunghezza del messaggio: in crittografia, di solito, la lunghezza del messaggio non è considerata segreta. Ci sono approcci che puoi aggiungere valori casuali alla fine o all'inizio o entrambi se questa è davvero una fuga di informazioni per te. L'approccio casuale dipende dal tuo caso di dati effettivo. È anche possibile utilizzare una dimensione fissa predeterminata poiché l'e-mail può essere limitata a 512 caratteri. Alla fine, almeno il limite superiore viene rivelato in tutti i casi.
Il riutilizzo della coppia (IV, chiave) è un vero problema che può eliminare la riservatezza con la tecnica del crib-drag. Questo non rivela la chiave di crittografia.
Mancanza di autenticazione Come tutte le modalità di crittografia non autenticate, la modalità CTR nuda manca di integrità e autenticazione. Un singolo bit di flipping può avere risultati catastrofici a causa della malleabilità della modalità CTR.
La modalità AES-GCM che utilizza la modalità operativa CTR ti fornisce tutto in una volta, tuttavia ha lo stesso problema di riutilizzo della coppia (IV, chiave). Esiste una modalità SIV (Synthetic Initialization Vector) come resistenza all'uso improprio del nonce ( carta , rfc8452 ) che elimina questo problema. La modalità SIV può ancora far trapelare che lo stesso messaggio viene inviato con la stessa chiave, quindi un osservatore può distinguerlo.
Distinzione di messaggi lunghi: la modalità CTR è progettata con una funzione Pseudo-Random (PRF). Quando si usa AES in modalità CTR, lo usiamo con Pseudo Random Permutation (PRP);$$E_k\colon \{0,1\}^n \to \{0,1\}^n.$$ Con PRP fintanto che i blocchi di messaggi non vengono ripetuti la sequenza $E_k(0), E_k(1), \dots, E_k(\ell - 1)$ con $\ell < 2^n$non viene ripetuto. Se il messaggio con length$\ell$-block non ha blocchi ripetuti, questo non è un problema. Se ci avviciniamo al messaggio come blocco casuale uniforme, ci aspettiamo una collisione$\ell \approx \sqrt{2^n} = 2^{n/2}$ dal paradosso / attacco del compleanno.
Se utilizzato con AES-128 per messaggi lunghi, verificare la ripetizione. La ripetizione consente all'attaccante di distinguere questo da casuale uniforme con probabilità non trascurabile .
In breve, un testo cifrato duplicato in qualsiasi posizione fa trapelare che i messaggi sono diversi.
Dimensione del messaggio per chiave: sebbene il NIST dica 64 nonce e contatore a 64 bit, si dovrebbe smettere di usare una chiave molto prima$2^{64}$bloccare. Ciò è dovuto all'utilizzo di un PRP (AES) invece di PRF in modalità CTR .
Altri vantaggi:
Non è necessaria la decrittografia: la modalità CTR non richiede la decrittografia del codice a blocchi, li utilizza sempre per la crittografia. Questo è molto utile in ambienti con vincoli. Semplifica anche il codice software e hardware.
Non è necessario il PRP: non è affatto necessario un codice a blocchi (PRP). Una funzione hash può essere utilizzata come nella serie ChaCha.
Prepocessing: il keystream generato dalla modalità CTR può essere preparato prima. Questo può aiutare a usare i buffer.
La modalità CTR ha la sicurezza CPA .
Un po 'di storia del CTR
La modalità CTR è stata introdotta da Whitfield Diffie e Martin Hellman nel 1979
Privacy e autenticazione: un'introduzione alla crittografia come documento invitato sugli atti dell'IEEE, 67 (1979), pp. 397–427.
A concrete Security of Treatment of Symmetric Encryption, Bellare et. al, 97 fornisce i limiti di sicurezza.
Guarda anche; Commenti al NIST in merito alle modalità operative AES: CTR-Mode Encryption , di Lipmaa et al. per altri dettagli di vantaggi e svantaggi.
Schneier e Ferguson hanno inizialmente consigliato la modalità CTR, ma sono passati a consigliare la modalità CBC a causa delle potenziali difficoltà nel garantire che il contatore non fosse mai riutilizzato con una chiave.
Mentre la tua domanda sembra concentrarsi sul lato CTR delle cose, vale la pena una risposta per discutere anche del lato AES delle cose. Ci sono almeno due situazioni in cui altri cifrari a blocchi possono essere più appropriati.
Calcolo sicuro :
Ci sono due principali "difficoltà" di AES rispetto al calcolo sicuro (che significa calcolo multipartitico e principalmente NIZK, ma probabilmente anche crittografia completamente omomorfa).
L'AES viene calcolato su un campo della caratteristica 2. Se un sistema MPC / FHE utilizza la caratteristica $p$ aritmetica, l'avere una cifra nella caratteristica 2 richiede conversioni tra diverse rappresentazioni (diciamo, di un elemento in $\mathbb{Z}/p\mathbb{Z}$, o la decomposizione in base 2 di un tale elemento) che sono più costosi rispetto al calcolo standard.
In generale, le moltiplicazioni sono molto più costose (relativamente) delle aggiunte nel contesto del calcolo sicuro. Ciò significa che si può avere un diverso "modello di costo" per cui costruire cifrari, dove si è più interessati a ridurre genericamente il numero di moltiplicazioni nel cifrario.
Un codice da esaminare per questo argomento è MiMC (sebbene recentemente si sia verificato un attacco parziale contro questo codice in un "$\mathbb{F}_{2^k}$ versione "di esso. Ha anche"$\mathbb{F}_p$"versioni, che non vengono colpite dall'attacco).
Sistemi incorporati :
Sulle macchine standard, l'implementazione hardware di AES (tramite l'istruzione AES-NI) fornisce una velocità di ~ 40 volte superiore rispetto alle implementazioni software ottimizzate di AES. Ciò rende difficile essere competitivi con AES quando si confronta AES-NI con le implementazioni software di altri cifrari. Ma quando non hai AES-NI, altri codici possono essere più competitivi. Questo post di Matthew Green discute l'uso di alternative ad AES (la sua raccomandazione quando scriveva questo ~ 8 anni fa non era di farlo, per la cronaca) discute di alcuni cifrari come Salsa20 che offre una velocità 2x - 3x su AES nel software. Nota che Salsa20 è tecnicamente un cifrario a flusso rispetto ad AES che è un cifrario a blocchi, ma questo è solo per motivare la possibilità di "battere" AES in velocità quando non hai accesso ad AES-NI.
Una fonte migliore per cifrature più veloci in ambienti di elaborazione vincolati è la standardizzazione NIST Lightweight Cryptography in corso . Non l'ho seguito da vicino, ma attualmente c'è molto interesse di ricerca nel trovare un nuovo codice da standardizzare per (essenzialmente) l'uso in sistemi embedded. Attualmente stanno pianificando di pubblicare i loro finalisti del terzo round il prossimo dicembre, quindi non mi sorprenderebbe se nei prossimi anni ci fosse un "nuovo cifrario" che sostituisce l'uso di AES nei sistemi embedded.
CTR è davvero una modalità operativa di cifratura a blocchi molto carina. I suoi principali svantaggi sono che:
- non protegge l'integrità del messaggio (e infatti consente a un utente malintenzionato di capovolgere facilmente bit arbitrari in un messaggio crittografato senza doverlo decrittografare), e
- potrebbe perdere testo in chiaro se un blocco contatore viene mai riutilizzato; in particolare, la crittografia in modalità CTR richiede un input nonce univoco che non deve assolutamente essere riutilizzato per due diversi messaggi crittografati con la stessa chiave.
Fortunatamente, entrambi questi problemi possono essere risolti utilizzando la modalità CTR come componente in una costruzione di livello superiore:
- Il primo problema può essere risolto utilizzando una modalità di crittografia autenticata , molte delle quali (come EAX e GCM ) si basano su una combinazione della modalità CTR con un codice di autenticazione del messaggio .
- Il secondo problema può essere risolto utilizzando una modalità di crittografia "resistente all'uso improprio nonce" che deriva il valore del contatore iniziale in base (tra le altre cose) al messaggio di testo in chiaro che viene crittografato. Tali modalità includono SIV e GCM-SIV , entrambe basate anche sulla modalità CTR e forniscono anche l'autenticazione dei messaggi come descritto sopra.
Ovviamente, l'aggiunta dell'autenticazione dei messaggi richiede un'elaborazione aggiuntiva che rende queste modalità più lente del CTR grezzo (sebbene una buona implementazione di GCM possa essere ancora molto veloce). In particolare, per ottenere la piena sicurezza che queste modalità garantiscono, il destinatario deve autenticare l'intero messaggio prima di trasmettere qualsiasi testo in chiaro decrittografato. Per le modalità resistenti all'uso improprio, lo stesso vale anche durante la crittografia, poiché l'intero messaggio deve essere elaborato per derivare il valore del contatore iniziale prima di poter essere crittografato.
Tuttavia è generalmente un piccolo prezzo da pagare per una maggiore sicurezza. Se è possibile utilizzare una modalità resistente all'uso improprio nonce come SIV o GCM-SIV, ti consiglio vivamente di farlo. In caso contrario, utilizza almeno una modalità AE non basata su CE come GCM.