Sto generando una chiave da una password per crittografare i dati con AES256. Dal momento che l'hash generato non è memorizzato, dovrei usare un sale? Se utilizzo un salt e viene reso pubblico, i miei dati crittografati sono meno sicuri?
Non vedo la necessità di proteggere dagli attacchi arcobaleno poiché l'hash generato non viene mai salvato ma utilizzato solo come chiave di crittografia e non esiste un repository centrale per i dati crittografati.
Risposta aggiornata in base alle nuove informazioni:
Gli umani non sono molto creativi quando si tratta di password. Ciò rende queste password una scelta sbagliata come semi per generare chiavi di crittografia (che dovrebbero avere un'alta entropia). Citando da un studio :
Burnett did an analysis of 6 million username and password combinations last year, and found that 91 percent of users had used one of the 1,000 most common passwords—with 99.8 percent using a password from the 10,000 most common. And "password" was the leader of them all, in use by 4.7 percent of user accounts.
Considerate le statistiche di cui sopra, è probabile che abbiate a che fare con un sottogruppo molto minuscolo di chiavi di crittografia totali possibili (un paio di migliaia o milioni!). Una chiave AES a 256 bit ha uno spazio di indirizzamento di 2 ^ 256. In tal caso, dovresti preoccuparti degli attacchi del dizionario.
Considera una funzione PBKD seguente:
IlPBKDFsoprautilizzaciterazionidiunafunzionehashHrispettoallacombinazione(password||salt)
Inoltre,consideraundizionariodellepassworddi1Mpasswordechelanostraapplicazioneha100utenti
Senzasale
Quandononcisonosaleperutente,lafunzionePBKDFsoprasiriducea:
Tutto ciò che l'utente malintenzionato deve fare è calcolare un dizionario di chiavi AES da 1 M corrispondenti a ciascuna password nel dizionario.
The number of times a user needs to run the KDF function = 1M.
Con sale
Ora che ogni utente ha un salt, un generico elenco 1M di chiavi AES non funzionerà . Un utente malintenzionato dovrà ora eseguire le operazioni 1M KDF per utente per creare un set specifico di possibili chiavi AES per quell'utente specifico .
The number of times a user needs to run the KDF function = 100M.
I PBKDF, come bcrypt e scrypt, sono deliberatamente funzioni lente solo per scongiurare attacchi di dizionario come questi.
Si consiglia di utilizzare un sale con le funzioni PBKDF per assicurarsi che le chiavi risultanti abbiano più entropia e che un utente malintenzionato debba calcolare un dizionario per utente per eseguire un attacco di forza bruta basato sul dizionario. Poiché le funzioni PBKDF sono progettate per essere lente, la creazione di un elenco di dizionari per utente è una grandezza dell'ordine più lenta di una singola lista.
I sali saranno utili nello scenario in cui due utenti diversi hanno le stesse password e gli stessi dati. Se viene utilizzata una crittografia deterministica, i testi di crittografia risultanti saranno uguali (poiché le chiavi di crittografia derivate utilizzando PBKDF saranno uguali) aprendo così i vettori per la crittoanalisi. Se le password sono salate, il testo cifrato risultante sarà diverso nel caso precedente.
I sali non sono un segreto. Non è necessario crittografare / nascondere i sali. Dovrebbero essere però unici per ogni utente.
Inoltre, se non si dispone di un concetto di utenti / passphrase, non è necessario utilizzare PBKDF per generare chiavi. Come menzionato da Lucas, puoi usare un generatore di numeri casuali sicuro per creare chiavi casuali direttamente.
PBKDF2 è usato per derivare una chiave da una passphrase, se stai solo generando le chiavi senza usare effettivamente una passphrase, puoi anche usare un generatore casuale sicuro per generare una serie di byte.
Un sale non rende i tuoi dati meno sicuri, i sali non sono considerati segreti.