AES-CTR con PBKDF2 per IV per l'archiviazione dei file sul server. Va bene?

0

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

    
posta Michael 21.04.2016 - 11:01
fonte

1 risposta

1

AES-128 for encryption because it's faster and supposedly as secure as -256

Sì e no. Se si prevede di archiviare i dati per un lungo periodo e si è preoccupati per gli attacchi post-quantici, 256 bit potrebbe essere l'opzione migliore. L'algoritmo di Grover riduce la complessità temporale del cracking di una chiave da 128 bit fino a circa 2 64 , che è probabilmente fattibile. Per 256-bit riduce la sicurezza associata a 2 128 operazioni che è ancora probabilmente irrealizzabile.

CTR-mode because I don't need authentication (as in CGM).

Nitpick: è GCM (Gallois / Counter Mode).

Il CTR è un'opzione ragionevole, ma sarai davvero aperto agli attacchi malleabilità se qualcuno ottiene l'accesso in scrittura al tuo dispositivo. Ad esempio, se si dovesse crittografare un'immagine del disco di sistema con GRUB installato, un utente malintenzionato potrebbe indovinare i byte di istruzioni come determinate posizioni nell'area del bootloader (è una posizione nota e il codice del bootloader è abbastanza statico su versons) quindi potrebbero backdoor il bootloader e quindi il tuo sistema operativo una volta decodificato e ripristinato il backup.

And because (I think) does not need padding which might open up some for vulnerabilities (as CBC)

Le vulnerabilità CBC sono principalmente oracle di riempimento , che si applicano principalmente in un ambiente interattivo. Sono quasi certamente irrilevanti in scenari di backup come questo. Se stai cercando una buona modalità di blocco da utilizzare per l'archiviazione, cerca qualcosa come XTS o XTX. Non so se OpenSSL li supporti però.

All stored files have a database record where I store the IV.

Personalmente, avrei solo anteposto o aggiunto l'IV ai dati dei file crittografati.

I also store the iteration count for the IV so I can go back and recalculate with more iterations if needed.

Hmm. Ok. Non capisco del tutto perché sia necessario PBKDF2 per generare un IV.

Encryption password is hardcoded and stored in server software. Same password for all files.

Questo è gravemente insicuro. La tua soluzione ha zero sicurezza, in quanto chiunque compromette il server può semplicemente decrittografare tutti i file.

IV is calculated with pbkdf2. @100,000 iterations, sha256, random 32bit salt.

Perché? Le IV sono pensate per essere uniche e non devono essere casuali o segrete. Esistono solo per garantire che la crittografia di più messaggi con la stessa chiave non sia insicura.

a password is needed for IV calculations as well. Can I use the same password as for encryption?

irrilevante. La tua IV dovrebbe essere solo un valore univoco per ogni file.

But I do wonder if pbkdf is really needed in my use case. Encryption/Decryption of files are done at the server in a queue-based manner, i.e. no user interaction is involved. So the need to slow down the hashing process doesn't seem to apply here.

È davvero irrilevante. Il tuo IV non ha bisogno di essere segreto, e in molti casi non è necessario che sia casuale, solo univoco.

Or have I misunderstood something?

Poche cose, sembra. Sembra che tu abbia inventato uno schema di crittografia di backup troppo complicato in cui potrebbe essere usato qualcosa di semplice come lo strumento di riga di comando openssl (vedi questa domanda StackOverflow ). Non essere Dave . Sembra che tu abbia una conoscenza ragionevole dei concetti crittografici, ma ciò non significa che dovresti progettare i tuoi schemi per qualcosa.

    
risposta data 21.04.2016 - 11:24
fonte

Leggi altre domande sui tag