Mantieni la chiave sensibile tra le richieste

La risposta breve alla tua domanda dichiarata è che non sapendo che l'IV rende AES, o qualsiasi codice a blocchi in una modalità operativa corretta, molto più impossibile alla forza bruta, in pratica rendendo la IV un'estensione della chiave. Per AES-256, la chiave a 256 bit più una IV a 128 bit richiede in sostanza che l'utente malintenzionato indovini correttamente una sequenza di 384 bit, richiedendo i peggiori tentativi 2 ^ 384. Mettendo questo in prospettiva, un computer che funziona a livello di elettroni al 100% di efficienza termica, dato che ogni fotone che il nostro Sole produrrà nella sua vita residua, sarebbe in grado di provare circa 2 ^ 218 chiavi prima che il Sole diventi nano nero.

Tuttavia, l'IV è necessario da entrambe le parti al fine di crittografare / decrittografare in qualsiasi modalità che ne utilizza uno, e così, come altre specifiche sullo schema di crittografia tranne la chiave effettiva che sarebbe condivisa tra le parti durante la negoziazione (come algoritmo, modalità, dimensione del blocco, dimensione della chiave) la IV è considerata informazione pubblica. È possibile nasconderlo, nello stesso modo in cui la chiave può essere scambiata in modo sicuro (offline, crittografia a chiave pubblica), ma non è necessaria.

Rispondendo a questa domanda, devo dire che ci sono molte informazioni che non hai fornito, il che rende impossibile rispondere alla più ampia domanda di "questo schema è sicuro". Ad esempio, in che modo la password dell'utente è correlata alla chiave (stai utilizzando un KDF o un altro schema "key-stretching"?) Quale modalità di utilizzo stai utilizzando per la crittografia AES (alcune modalità sono più sicure di altre e alcune sono effettivamente rotti). EDIT: la modalità CBC non è una scelta terribile (ci sono peggio), ma occorre fare attenzione per garantire che il tuo codice non possa essere utilizzato come "padding oracle"; una "scatola nera" che dirà a un aggressore se un particolare messaggio di testo cifrato, quando decrittografato, è adeguatamente riempito. Questo può essere usato per decodificare il messaggio in chiaro dal noto testo cifrato senza conoscere la chiave. Poiché questo è solo un processo lato server e quindi non è disponibile alcun codice client da utilizzare per decrittografare, un utente malintenzionato dovrebbe penetrare abbastanza lontano per essere in grado di trasformare il codice server in un oracle di riempimento, ma mai assumere; se hai una buona implementazione a tua disposizione, sceglierei una modalità autenticata, come GCM o CCM, che resisterà agli attacchi di padding-oracle.

Dirò anche che questo schema sembra essere solo lato server; se la chiave e IV sono memorizzati solo sul server, allora tutta la crittografia e la decrittografia devono esserci, il che significherebbe che, a meno che non si stia utilizzando qualcos'altro come SSL per inviare dati al client, la sicurezza di questo particolare pezzo è carina discutibile.

Sì, l'IV imposta lo stato iniziale del flusso utilizzato per generare il testo cifrato. Senza IV, si otterrebbe un flusso diverso e la decifrazione fallirebbe. A seconda della modalità di funzionamento, quanto potrebbe fallire potrebbe essere diverso. Non sono sicuro, tuttavia, perché chiedi di scoppiarlo senza la flebo. Sembra che tu stia parlando della decrittazione. Mentre il IV è necessario, non è un segreto. Va bene che l'IV sia conosciuto, impedisce solo gli attacchi confrontando messaggi simili crittografati con la stessa chiave. La chiave è tutto ciò che deve rimanere segreto.

Se la chiave è compromessa, ci sono attacchi che indeboliscono enormemente la crittografia nella maggior parte delle modalità operative. Mentre l'IV è segreto aumenta leggermente la sicurezza, averlo rivelato non è catastrofico per la sicurezza della crittografia. La segretezza della chiave è tuttavia fondamentale dato che la segretezza della IV probabilmente non proteggerà un messaggio se la chiave è nota.

La maggior parte delle preoccupazioni relative al dirottamento di sessione e simili è valida, ma non compromette immediatamente i dati sul server. La mia raccomandazione sarebbe quella di criptare la chiave utente dopo che è stata inizialmente ottenuta con un'altra chiave di sessione a tempo, dividere la chiave in tre parti (o crittografarla con 3 diverse chiavi di sessione) e quindi inserire un pezzo di IV (o l'appropriato IV) e un pezzo della chiave (o 1 delle 3 chiavi) in ciascuno dei 3 posti come gettone. Quindi, quando vengono fornite tutte e tre le informazioni, la chiave effettiva può essere decifrata, ma qualsiasi pezzo compromesso non avrebbe alcun vantaggio al di fuori della sessione e la chiave di decifrazione reale sarebbe disponibile solo per il server dopo i 3 pezzi della chiave di sessione sono forniti in alternativa alla password.

L'utilizzo di 3 chiavi di sessione separate fornirà maggiore sicurezza, ma richiederà anche maggiore potenza di elaborazione. Una semplice suddivisione fornirà comunque una protezione aggiuntiva a seconda della modalità di funzionamento del codice ed è più economica da fare.

La cosa principale è che non si vuole mai rivelare la chiave di decodifica effettiva o alcuna informazione sulla chiave di decodifica dei dati per l'utente malintenzionato (o client) e non si desidera che non sia protetta nel DB (a riposo). Ciò significa che è necessario memorizzare la chiave dati in modo tale che sia protetta dalle informazioni che solo il client conosce e suddividendo le informazioni su tre pezzi per comprometterne la difficoltà.