Non vedo come "-salt" nello strumento da riga di comando openssl migliori la sicurezza a tutti

13

Lo faccio per crittografare un singolo file:

openssl aes-256-cbc -a -salt -in file.txt -out file.enc

e quindi digitare una password normale in chiaro.

Non capisco come -salt aumenti la sicurezza di questo. Il motivo è che il sale è memorizzato proprio lì all'inizio del file in questo modo:

Salted__<eight salt bytes>

Il sale è disponibile per il cracker in modo così ovvio, qual è lo scopo di esso? Non vedo come renderebbe un dizionario più difficile da attaccare ... soprattutto considerando il fatto che, per quanto ne so, openssl utilizza solo una iterazione per generare l'IV dalla password / salt - correggimi se io ' m sbagliato.

    
posta SecurityClown 26.10.2012 - 13:54
fonte

2 risposte

21

Il punto del sale è prevenire attacchi di precomputazione, come tabelle arcobaleno . Senza sale, chiunque potrebbe solo generare un enorme dizionario di hash e dei relativi testi in chiaro, e immediatamente violare qualsiasi hash noto. Con il sale, un tale dizionario è inutile, dal momento che è impossibile generare un tale dizionario per tutti i possibili sali.

Ho fatto un approfondimento piuttosto approfondito che copre questo problema all'indirizzo Come conservare il sale? , che vale la pena leggere.

    
risposta data 26.10.2012 - 14:09
fonte
11

OpenSSL usa il sale in combinazione con la password per generare due valori: il IV e la chiave di crittografia effettiva.

  • La chiave di crittografia deve essere derivata dalla password e dai dati presenti nell'intestazione del file (perché vogliamo poter decodificare il file solo con la conoscenza della password). Tuttavia, non vogliamo ottenere la stessa identica chiave ogni volta che usiamo la stessa password, altrimenti gli autori di attacchi potrebbero tentare di interrompere i file N a un costo inferiore rispetto a N volte costo di rompere uno. Un esempio di condivisione dei costi è rappresentato da tabelle precompute (tabelle di mapping da password a chiave), tabelle arcobaleno che rappresentano un caso speciale di tabelle precalcolate.

  • Il IV deve essere il più uniformemente casuale possibile; anche in questo caso, due file distinti dovrebbero utilizzare IV distinta, anche se crittografati con la stessa password. Un possibile progetto sarebbe stato quello di aggiungere la IV nell'intestazione del file (dopotutto, la IV non è pensata per essere segreta - altrimenti la chiameremmo una chiave, non una IV). Gli sviluppatori di OpenSSL preferivano derivare la IV dalla password, proprio come la chiave (cioè producono dalla password una lunga sequenza, che dividono in due, una metà è la chiave di crittografia, l'altra metà è la IV). Ciò è valido, purché nel mix sia stato aggiunto qualche elemento distinto, poiché due file distinti devono avere un IV distinto. Anche il sale lo fa.

Si noti che il metodo di crittografia utilizzato da OpenSSL non è standard; è "cosa fa OpenSSL" ma non è documentato ovunque tranne nel codice sorgente OpenSSL. Come formato di file di crittografia, è un po 'pidocchioso. In particolare:

  • Sembra che non ci sia modo di configurare il numero di iterazioni da utilizzare nella derivazione password-to-key. Questo è un problema perché lentezza configurabile è importante per far fronte al problema principale delle password, che sono, dopo tutto, password, cioè cose con entropia non troppo alta nel migliore dei casi.

  • Il sistema di crittografia non include un MAC quindi le alterazioni non sono necessariamente rilevate (non vengono rilevate < em> a tutti se gli ultimi due blocchi del file imbottito non sono modificati).

Pertanto, sei incoraggiato a utilizzare, se possibile, uno strumento migliore per la crittografia basata su password dei file. Ad esempio GnuPG .

    
risposta data 26.10.2012 - 14:47
fonte

Leggi altre domande sui tag