it-swarm-eu.dev

Calcola la chiave di crittografia AES dato il testo in chiaro e il suo testo cifrato?

Ho il compito di creare tabelle di database in Oracle che contengono stringhe crittografate (ovvero, le colonne sono RAW). Le stringhe vengono crittografate dall'applicazione (utilizzando AES, chiave a 128 bit) e archiviate in Oracle, successivamente recuperate da Oracle e decrittografate (ovvero Oracle non vede mai le stringhe non crittografate).

Mi sono imbattuto in questa colonna che sarà una delle due stringhe. Sono preoccupato che qualcuno noterà e presumibilmente capirà quali sono questi due valori per capire la chiave AES.

Ad esempio, se qualcuno vede che la colonna è Ciphertext # 1 o # 2:

  • Testo cifrato n. 1:

    BF,4F,8B,FE, 60,D8,33,56, 1B,F2,35,72, 49,20,DE,C6.
    
  • Testo cifrato n. 2:

    BC,E8,54,BD, F4,B3,36,3B, DD,70,76,45, 29,28,50,07.
    

e conosce i corrispondenti Plaintexts:

  • Testo in chiaro n. 1 ("Detroit"):

    44,00,65,00, 74,00,72,00, 6F,00,69,00, 74,00,00,00.
    
  • Plaintext # 2 ("Chicago"):

    43,00,68,00, 69,00,63,00, 61,00,67,00, 6F,00,00,00.
    

può dedurre che la chiave di crittografia è "Buffalo"?

42,00,75,00, 66,00,66,00, 61,00,6C,00, 6F,00,00,00.

Sto pensando che dovrebbe esserci solo una chiave a 128 bit che potrebbe convertire il testo in chiaro n. 1 in testo cifrato n. 1. Questo significa che dovrei invece utilizzare una chiave a 192 o 256 bit o trovare qualche altra soluzione?

(A parte questo, ci sono altri due cifratix per gli stessi caratteri semplici ma con una chiave diversa.)

  • Testo cifrato n. 1 A ("Detroit"):

    E4,28,29,E3, 6E,C2,64,FA, A1,F4,F4,96, FC,18,4A,C5.
    
  • Testo cifrato # 2 A ("Chicago"):

     EA,87,30,F0, AC,44,5D,ED, FD,EB,A8,79, 83,59,53,B7.
    

[Domanda correlata: Quando si utilizza AES e CBC, IV può essere un hash del testo in chiaro? ]

31

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

La domanda è: poter derivare le chiavi AES. A tale proposito, la risposta accettata è corretta: si chiama a Attacco in chiaro e AES è resistente a quel tipo di attacco. Quindi un utente malintenzionato non sarà in grado di sfruttare questo per ottenere la chiave e farcela con l'intero database.

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

L'indistinguibilità del testo cifrato è una proprietà di molti schemi di crittografia. Intuitivamente, se un sistema crittografico possiede la proprietà di indistinguibilità, un avversario non sarà in grado di distinguere coppie di cifrati in base al messaggio che crittografano.

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

Mitigazione: Per proteggerti, rendi la tua crittografia non deterministica (o almeno sembri non deterministica per l'attaccante) in modo tale che la crittografia ripetuta della stessa il testo in chiaro produce testi di cifratura diversi. Ad esempio, è possibile farlo utilizzando AES in modalità Cipher Block Chaining (CBC) con un casuale Initialization Vector (IV) . Utilizzare un generatore di numeri casuali sicuri per generare un nuovo IV per ogni riga e memorizzare il IV nella tabella. In questo modo, senza la chiave, l'attaccante non può dire quali righe hanno un testo in chiaro corrispondente.

45
Mike Ounsworth

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

Alcune cose possono ancora essere dette, però:

  • Avere un testo in chiaro e il testo cifrato corrispondente consente a un utente malintenzionato di verificare un valore chiave potenziale.
  • Il 2n-1Il valore è in realtà la metà della dimensione dello spazio chiave. L'idea è che l'attaccante può provare tutti i tasti possibili, fino a quando uno corrisponde. In media, dovrà provare metà delle chiavi prima di premere quella giusta. Ciò presuppone che lo spazio chiave abbia dimensioni 2n. 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 chiavi possibili è molto più basso (non devono esserci più di 100000 città negli Stati Uniti) . Quindi, ottieni la sicurezza promessa a 128 bit solo se il tuo processo di generazione della chiave può effettivamente produrre qualsiasi chiave a 128 bit.
  • Apparentemente crittografate 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 utente malintenzionato può accorgersene. In altre parole, perdi informazioni su quali celle sono uguali tra loro. A seconda della situazione, questo potrebbe essere o meno un problema; dovresti esserne consapevole.
  • Non si dice come si gestiscono valori più lunghi di 16 byte. Questo non è un problema semplice. In generale, ciò richiede un modalità concatenamento come CBC e un Inizializzazione vettoriale (dipende dalla modalità; per CBC, un valore casuale di 16 byte - un nuovo IV per ciascuno valore crittografato) (questo può anche correggere la perdita di informazioni dal punto precedente).
15
Thomas Pornin

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

Post scriptum Ho notato che qualunque cosa tu stia usando per la crittografia non sembra usare 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 crittografare lo stesso messaggio più volte ti dia sempre lo stesso testo cifrato ogni volta è una perdita di sicurezza che è meglio evitare. È possibile evitare questa perdita utilizzando una modalità operativa standard con un IV appropriato. (Probabilmente dovresti anche usare un codice di autenticazione dei messaggi (MAC) per autenticare il testo cifrato e impedirne la modifica.)

5
D.W.

Saltare la crittografia.

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

https://stackoverflow.com/questions/5051007/what-is-the-purpose-of-salt

3
Morons

AES non è così semplice come costruire un tavolo Rainbow. La prima cosa che devi capire è che la tabella richiede un vettore di inizializzazione. Fintanto che stai cambiando questo su una base semi regolare la costruzione di un tavolo Rainbow (che non è davvero realistico.) Richiederebbe molto tempo. Ordini di grandezza lunghi. Dato che una tipica tabella Rainbow avrebbe essenzialmente 2 dimensioni, sarebbe necessario essenzialmente un cubo di set di risultati per capire sia la IV che la chiave.

Se leggi il post di Thomas Pornin, entra in un dettaglio abbastanza grande su cosa significhi, in termini di forzatura bruta del risultato.

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

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

2
Ori