Ho cercato di comprendere abbastanza crittografia / hashing per poter implementare una memoria sicura per i file, lato server. Quando lo avrò ragionevolmente al sicuro, lo esaminerò con un esperto. Non ha senso chiamare l'esperto prima di capirlo a un livello ragionevole.
Per favore qualcuno potrebbe dirmi se lo sto facendo bene, e anche se ci sono parti ridondanti di cui non ho bisogno.
Ecco la mia configurazione attuale:
-
OpenSSL
-
AES-128 per la crittografia perché è più veloce e apparentemente sicuro come -256
-
Modalità CTR perché non ho bisogno dell'autenticazione (come in CGM). E perché (penso) non ha bisogno di padding che potrebbe aprirne alcuni per vulnerabilità (come CBC)
-
Tutti i file memorizzati hanno un record del database in cui memorizzo IV.
-
Memorizzo anche il conteggio delle iterazioni per l'IV, così posso tornare indietro e ricalcolare con più iterazioni, se necessario.
-
IV è 16 byte per corrispondere alla dimensione del blocco a 128 bit
-
La password di crittografia è hardcoded e archiviata nel software del server. La stessa password per tutti i file.
- Quanto dovrebbe durare questa password casuale?
-
IV è calcolato con pbkdf2. @ 100.000 iterazioni, sha256, sale a 32 bit casuale.
- è necessaria anche una password per i calcoli IV. Posso usare la stessa password della crittografia?
Ma mi chiedo se pbkdf sia davvero necessario nel mio caso d'uso. La crittografia / decrittografia dei file viene eseguita sul server in modalità basata su code, ovvero non è coinvolta l'interazione dell'utente. Quindi la necessità di rallentare il processo di hashing non sembra applicarsi qui. O ho frainteso qualcosa? Ho solo bisogno di un IV casuale e unico, non ho bisogno di prendere tempo, però ..
modifica - >
Una soluzione più semplice sarebbe quella di non usare un IV (cioè IV = 0) e invece usare pbkdf per creare una password di crittografia univoca per ogni file. L'unico inconveniente che posso vedere con questo è che i miei file sarebbero all'opinione se qualcuno fosse arrivato al database.
Con la soluzione sopra descritta un add attaccante avrebbe bisogno di prendere l'IV dal database e la password dal server (e naturalmente il file da decifrare).
Sarebbe considerato stupido omettere la IV e utilizzare invece password univoche e casuali.
< ---
modifica di nuovo --- > >
Dopo aver riflettuto un po 'sulla risposta e sui commenti Polynomials mi rendo conto che devo fare marcia indietro.
Il più grande problema di cui sopra è che diventa non sicuro nel momento in cui memorizzo la password da qualche parte. Solo alcuni dei file sono effettivamente sensibili. Quando i file sensibili richiedono la crittografia, chiederò all'utente una password tramite un'app per bloccare e sbloccare i file. La password verrà memorizzata solo nella memoria e lascerò all'utente la password.
Avrò dei problemi quando più di un server può servire l'app. Potrei risolverlo non caricando il bilanciamento del percorso per la password, quindi questa piccola attività viene gestita da un solo server. Altrimenti dovrei comunicare la password tra i server in modo che tutti lo abbiano in memoria.
Phew .. Questa cosa di sicurezza ci mette davvero un po 'a pensare a un tipo di database / server / app di tipo normale. Farei meglio a tornare su qualche codifica produttiva per un po 'e rivisitarlo più tardi ..
< < ---
Grazie in anticipo, // Michael