Probabilmente dovrebbe trovarsi nello Crypto Stack Exchange anziché qui.
Indipendentemente da ciò, la migliore linea di condotta è quella di non toccare te stesso il codice a blocchi simmetrico. Esistono librerie di sicurezza mature, controllate da crittografi come NaCl e KeyCzar che prenderà le decisioni corrette per te.
Detto questo, se fai scegli di farlo tuo, una scelta generalmente sicura è AES-128 in modalità EAX o GCM. Entrambe queste modalità forniscono l'autenticazione del tuo testo cifrato oltre alla sicurezza crittografica, che è fondamentale per evitare cose come il riempimento degli attacchi di Oracle. Per utilizzare una di queste modalità, è necessaria una chiave crittografica, un vettore di inizializzazione, un testo in chiaro e, facoltativamente, ulteriori dati di autenticazione.
Il tasto deve essere lungo 128 bit e generato con un generatore di numeri casuali protetto da crittografia. Se si desidera una chiave protetta da password, prendere la chiave generata a caso e passarla attraverso PBKDF2-HMAC-SHA-256 con la password, la chiave al posto del sale, un numero di cicli calibrati da prendere per tutto il tempo necessario mi sento a mio agio con (10_000 round sul mio laptop richiedono 0,5 secondi, che è una quantità ragionevole di tempo) e una dimensione di output a 128 bit. L'output sarà la chiave "reale" da utilizzare ed è possibile rieseguire questo con la chiave e la password originali ogni volta che è necessario accedere alla chiave reale.
Il vettore di inizializzazione per le modalità EAX e GCM (nota: questo può non essere il caso per altre modalità, come CBC, che ha requisiti IV anche più rigidi) deve essere univoco in tutte le crittografie con un dato chiave. Un semplice contatore è considerato sufficiente. Tuttavia, è necessario assicurarsi che questo contatore garantisca univocità anche quando si eseguono più invocazioni del processo, più processi simultanei e più macchine. Un UUID versione 1 correttamente implementato dovrebbe essere sufficiente per questi scopi. Questo non è nel formato incoraggiato da RFC 5116, sezione 3.2 , tuttavia, e qualcuno più esperto di me chiarire se tale formato è importante da rispettare. In alternativa, un numero casuale generato in modo sicuro dovrebbe essere sufficiente, ma non ho visto persone farlo in pratica con le modalità derivate dal CTR (che sono basate su GCM ed EAX). Ancora una volta, qualcuno più esperto dovrà commentare se questa è una buona idea.
Il testo in chiaro può essere qualsiasi cosa tu voglia, ma non cadere nella trappola di pensare che l'input di AES sia "caratteri", "ASCII", "Unicode" o qualsiasi assurdità. L'input appropriato è un array di byte .
I dati di autenticazione associati facoltativi possono anche essere qualsiasi cosa tu voglia. Si tratta di dati incorporati nel testo cifrato per verificare l'autenticità quando viene eseguita una decrittografia. Ma non fa parte del testo in chiaro protetto all'interno del testo cifrato. Ad esempio, se si stanno crittografando dati per conto di utenti archiviati in un database, è possibile utilizzare user_id dell'utente nel database. Nel caso in cui un utente abbia trovato un modo per copiare i dati crittografati di un altro utente nel suo account, non sarebbe in grado di far decrittografare l'applicazione, poiché il suo user_id non corrisponderebbe a quello utilizzato per crittografare i dati. Potrei averlo spiegato male, quindi per favore fatemi sapere se è stato confuso o poco chiaro.
Per la memorizzazione, la chiave deve essere tenuta segreta. La gestione delle chiavi e la durata sono al di fuori della portata della mia risposta, ma è una parte fondamentale per garantire la sicurezza dei dati protetti. Il vettore di inizializzazione, il testo cifrato e i dati di autenticazione non hanno alcun requisito sulla loro segretezza, ma i dati di autenticazione dovrebbero idealmente essere forniti al livello di crittografia da un'origine esterna (ad esempio, user_id menzionato in precedenza). Se usato, non dovrebbe essere qualcosa che un potenziale attaccante può fornirti o altrimenti esercitare il controllo. La memorizzazione, la trasmissione e la copia dei dati di autenticazione insieme agli altri valori vanifica lo scopo. Un modo di considerare i dati di autenticazione è che dovrebbe fornire "contesto" per i dati protetti.
Questo dovrebbe farlo Tieni presente che questo è complicato e estremamente difficile da eseguire correttamente senza perdite di informazioni protette. Non ti consiglio di farlo da solo, ma se lo fai, quanto sopra dovrebbe essere un punto relativamente sicuro da cui partire. Per lo meno, dovresti stare meglio del 95% dei siti web che cercano di implementare la crittografia da soli. Supponendo, ovviamente, di non aver completamente fallito nel descrivere un approccio di implementazione sicuro.