-
Stai condividendo IV: le celle di una determinata riga useranno la stessa IV. Questo è male . Non farlo.
-
Utilizzi CBC; questa è una modalità nota per avere alcuni problemi di sicurezza (in particolare, è sensibile a "quanto random" è la IV), e coinvolgerà padding (poiché CBC crittografa solo blocchi completi , devi estendere gli elementi di dati alla dimensione successiva che è un multiplo della dimensione del blocco).
-
Se si modifica una delle celle crittografate, è necessario reencrittarla. Se usi la stessa chiave e la stessa IV, allora hai perso (per quanto riguarda la sicurezza). Pertanto, è necessario modificare l'IV per quella cella. Se usi la stessa IV per l'intera riga (che è male), allora devi ricodificare anche le altre celle della riga.
-
Un MAC è necessario se i potenziali attaccanti possono modificare i dati in posizione ; non lo è se si presume che gli aggressori siano solo passivi. Si noti che un utente malintenzionato potrebbe modificare i dati crittografati per osservare il modo in cui reagisce il sistema e tentare di dedurre informazioni sui dati crittografati. Come regola generale, stai meglio con un MAC che senza.
Suggerirei quindi di modificare il tuo schema nel modo seguente:
- Utilizza una modalità di crittografia autenticata con dati associati che combina crittografia e integrità, come EAX o GCM .
- Utente un IV per cella, memorizzato nella cella stessa. EAX e GCM non hanno bisogno di un random IV, solo un IV che non viene mai ripetuto (per una determinata chiave), quindi potresti usare un semplice contatore: mantieni un contatore globale a livello di sistema, incrementato ogni volta è necessario crittografare un nuovo valore di cella (quando si assegna una cella e anche quando si sostituisce il contenuto della cella); memorizza il contatore nella cella stessa (in questo modo, un contatore a 64 bit sarà sufficiente, non è necessario passare a un valore di 128 bit completo).
- Le modalità AEAD includono un controllo di integrità che viene calcolato sui dati che sono crittografati e alcuni dati aggiuntivi che è possibile scegliere (i "dati aggiuntivi" vengono utilizzati per il calcolo ma non vengono memorizzati nella crittografia risultato, è necessario fornire di nuovo su decrittografia, in modo che il MAC integrato possa essere controllato). Codifica in questi "dati aggiuntivi" i numeri di riga e di colonna per la cella. In questo modo, un malvagio attacker active non sarà in grado di scambiare silenziosamente il contenuto della cella (il MAC sarà OK solo se il contenuto della cella è ancora dove dovrebbero essere).
Inoltre, non indulgere nella fantasia della "chiave master rotante". L'unica ragione per cui dovresti cambiare la chiave principale è nel caso in cui sia stata rubata; e, in quel caso, devi cambiarlo subito per l'intero database . Non c'è bisogno di una transizione graduale e graduale: questa è una situazione di emergenza. Pertanto, non è necessario mantenere un numero di versione per la chiave master. Un identificatore per l'algoritmo crittografico, d'altra parte, è una buona idea; può stare su un singolo byte (o anche meno di quello).
Encrypt i dati binari, non una codifica Base64 di esso. La crittografia output sarà comunque binaria. L'applicazione di Base64 sull'input renderà i dati più grandi del 33%, senza una buona ragione.