I salts e l'hashing della password sono necessari per le chiavi casuali?

Sembra che tu stia mischiando diversi casi d'uso qui. Un caso d'uso è ottenere una chiave di crittografia da un segreto. L'altro sta memorizzando i dati di accesso.

Se è necessario ricavare una chiave di crittografia bit n per un codice simmetrico come suggerisce l'esempio AES, il meglio che si possa sperare è i bit n o l'entropia. Se hai una vera fonte casuale e la usi per generare tutti i bit n in modo indipendente, questa è la massima entropia possibile. L'hashing dei dati al meglio non diminuirà l'entropia.

Se il tuo contributo è una frase d'accesso fornita dall'utente, una funzione di derivazione della chiave deve essere usato per condensare l'entropia della stringa di lunghezza arbitraria nel numero di bit previsti dal cifrario. Una semplice funzione di hash può essere utilizzata come funzione di derivazione chiave ma non sarà molto sicura. Le frasi passate dell'utente spesso hanno un'entropia molto scarsa. L'obiettivo è quello di rendere la valutazione della funzione di derivazione della chiave così costosa che l'attacco alla passphrase non è più efficace della forzatura bruta dei bit chiave. Nel tuo caso, la funzione di identità fornisce già questa proprietà, tuttavia.

Un caso d'uso diverso è la memorizzazione dei dati di accesso in un database. Qui, hashing e salting non sono usati per "rendere le password più sicure" ma per rendere difficile indovinare la password effettiva anche nel caso in cui l'hacker si impadronisca del database. Se il database contiene le password in formato testo, non importa quanto lunga e casuale sia la password. L'autore dell'attacco può sempre leggerlo direttamente.

Adotta il seguente motto: le password e le chiavi crittografiche non sono la stessa cosa . Alcuni contrasti:

• Le password vengono scelte dagli esseri umani con il loro cervello, ma le chiavi sono generate casualmente con un generatore sicuro.
• Le password sono alfanumeriche, ma le chiavi sono binarie.
• Le password sono di lunghezza variabile, con gli umani che scelgono individualmente la lunghezza. Ma i tasti sono di lunghezza fissa, con il sistema che sceglie le lunghezze.
• Le password sono umane memorabili, ma le chiavi non devono essere così, e sono invece memorizzate in modo sicuro.
• Le password sono un fattore "qualcosa che conosci", ma le chiavi sono un fattore "qualcosa che hai".

But are salts and hashes really needed if you have a truly random key and not a password entered by a user? For instance, suppose the password is a "ridiculously" long string of random printable (or better yet, pure binary) characters, for instance 256 random bytes for an AES256 cipher.

La risposta breve alla tua domanda è che le chiavi non hanno bisogno di hashing della password, ma il problema qui è che stai parlando di password e chiavi come se fossero intercambiabili, e questa è una bandiera rossa. Se il tuo programma di crittografia consente all'utente di digitare password alfanumeriche a lunghezza variabile di loro scelta, allora quel programma ha davvero bisogno di applicare una funzione di derivazione della chiave ad alta intensità di risorse alla password scelta dall'utente. Se l'utente ha scelto una password veramente strong, non sarebbe necessario eseguire l'hashing lento, ma un programma di crittografia basato su password deve presupporre che la password sia debole.

Viceversa, se il programma è progettato per utilizzare chiavi crittografiche avanzate, non dovrebbe consentire all'utente di sceglierle con il loro cervello o inserirle con la loro mano. Dovrebbe supportare queste opzioni:

1. Genera una chiave strong e scrivila su un file.
2. Utilizza una chiave memorizzata in tale file.
3. Utilizza smart card crittografiche anziché file.