Calcola la chiave di crittografia AES in base al testo in chiaro e al testo cifrato?

Sto aggiungendo una risposta come wiki della comunità perché ritengo che la risposta accettata sia pericolosamente fuorviante . Ecco il mio ragionamento:

La domanda è chiedere di poter derivare le chiavi AES. A tale proposito la risposta accettata è corretta: si tratta di un Attacco di testo in chiaro noto e AES è resistente a tale tipo di attacco. Quindi un utente malintenzionato non sarà in grado di sfruttare questo per ricavare la chiave e fare fuori tutto il database.

Ma c'è un altro, potenzialmente pericoloso attacco in gioco qui: a Ciphertext Indistinguishablity Attack . Da Wikipedia:

Ciphertext indistinguishability is a property of many encryption schemes. Intuitively, if a cryptosystem possesses the property of indistinguishability, then an adversary will be unable to distinguish pairs of ciphertexts based on the message they encrypt.

L'OP ci ha mostrato che questa colonna contiene uno dei due possibili valori, e poiché la crittografia è deterministica (cioè non usa un IV casuale), e l'attaccante può vedere quali file hanno lo stesso valore l'una dell'altra. Tutto ciò che l'utente malintenzionato deve fare è capire il testo in chiaro per quella colonna per una singola riga, e hanno incrinato la crittografia sull'intera colonna. Cattive notizie se desideri che i dati rimangano privati, il che presumo sia il motivo per cui l'hai crittografato in primo luogo.

Mitigazione: Per proteggerlo, rendere la crittografia non deterministica (o almeno non apparire deterministica per l'autore dell'attacco) in modo che le ripetute crittografie dello stesso testo in chiaro producano testi di cifratura diversi. Ad esempio, puoi farlo utilizzando AES nella modalità Cipher Block Chaining (CBC) con una scelta casuale Inizializzazione vettoriale (IV) . Utilizza un generatore di numeri casuali sicuro per generare un nuovo IV per ogni riga e memorizzare l'IV nella tabella. In questo modo, senza la chiave, l'autore dell'attacco non può stabilire quali righe hanno il testo in chiaro corrispondente.

Per un codice a blocchi con una chiave n -bit, se, dato un blocco di testo in chiaro e il testo cifrato corrispondente, la chiave può essere indovinata in meno di 2 ^n-1 passo in media, allora quel codice a blocchi sarà detto "rotto" e i crittografi faranno il punto di non usarlo. L'AES non è rotto (ancora). Quindi non preoccuparti.

Tuttavia, alcune cose possono ancora essere dette:

• Avere un testo in chiaro e il testo cifrato corrispondente consente a un utente malintenzionato di verificare un potenziale valore-chiave.
• Il valore 2 ^n-1 è in realtà metà delle dimensioni dello spazio della chiave. L'idea è che l'attaccante possa provare tutte le possibili chiavi, fino a quando non ci si abbina. In media, dovrà provare metà dei tasti prima di colpire quello giusto. Ciò presuppone che lo spazio della chiave abbia la dimensione 2 ⁿ . Hai ancora la possibilità di ridurre lo spazio delle chiavi: ad esempio, se decidi che la tua chiave è il nome di una città degli Stati Uniti, il numero di possibili chiavi è molto più basso (non ci devono essere più di 100000 città negli Stati Uniti) . Quindi, si ottiene la sicurezza a 128 bit promessa solo se il processo di generazione della chiave può effettivamente produrre una chiave a 128 bit.
• A quanto pare, crittografa ogni valore inserendolo direttamente in un core AES. Essendo AES deterministico, ciò significa che due celle con lo stesso valore produrranno lo stesso blocco crittografato e qualsiasi attaccante potrebbe accorgersene. In altre parole, si perdono informazioni su quali celle sono uguali tra loro. A seconda della situazione, questo può o non può essere un problema; dovresti esserne a conoscenza.
• Non dici come gestisci valori più lunghi di 16 byte. Questo non è un problema semplice. In generale, ciò richiede una modalità di concatenamento come CBC e un Vettore di inizializzazione ( dipende dalla modalità, per CBC, un valore casuale di 16 byte - una nuova IV per ogni valore crittografato) (questo può anche correggere la fuga di informazioni dal punto precedente).

La risposta: No, la chiave AES non può essere recuperata in questo scenario. AES è sicuro contro attacchi con testo in chiaro. Ciò significa che, anche se un utente malintenzionato conosce il testo in chiaro e il relativo testo cifrato (la sua crittografia sotto una chiave AES sconosciuta), l'autore dell'attacco non può recuperare la chiave AES. In particolare, l'attaccante non può recuperare la chiave AES più velocemente del semplice tentativo di possibili chiavi una dopo l'altra - che è un processo che richiederà più tempo della vita della nostra civiltà, supponendo che il tasto AES sia scelto casualmente.

P.S. Ho notato che qualsiasi cosa tu stia utilizzando per la crittografia non sembra utilizzare un IV. Questo è un rischio per la sicurezza. Non so quale modalità di funzionamento stai utilizzando, ma dovresti utilizzare una modalità di crittografia ben considerata (ad esempio, crittografia in modalità CBC, crittografia in modalità CTR) con un IV casuale. Il fatto che la crittografia dello stesso messaggio più volte ti registri sempre lo stesso testo cifrato è una perdita di sicurezza che è meglio evitare. È possibile evitare questa perdita utilizzando una modalità standard di funzionamento con un IV appropriato. (Probabilmente dovresti anche usare un codice di autenticazione del messaggio (MAC) per autenticare il testo cifrato e impedirne le modifiche.)

Saltare la crittografia.

In questo modo non ci saranno schemi nella tua crittografia. (Ci sono anche altri vantaggi!)

link

AES non è facile come costruire un tavolo arcobaleno. La prima cosa che devi capire è che la tabella richiede un vettore di inizializzazione. Finché stai cambiando questo su base semi-regolare, la costruzione di una tabella arcobaleno (che non è molto realistica.) Richiederebbe molto molto tempo. Ordini di grandezza lunghi. Poiché una tipica tabella arcobaleno sarebbe essenzialmente di 2 dimensioni, in pratica è necessario un cubo di set di risultati per capire sia la IV che la chiave.

Se leggi il post di Thomas Pornin, entra in dettagli molto dettagliati su cosa significhi, in termini di forza bruta che costringe il risultato.

La preoccupazione realistica è che qualcuno con accesso al database sia in grado di iniettare una stringa da un altro campo (presumibilmente perché non stai usando un valore di padding casuale nella colonna per elemento o seeding.)

Se assegni il valore non avrai questo problema e l'unico (realistico) attacco al testo cifrato è reso molto più difficile.