it-swarm.dev

Perché avresti bisogno di un sale per AES-CBS quando IV è già generato casualmente e memorizzato con i dati crittografati?

Stavo guardando questo codice e mi sono imbattuto in questi commenti che dicono che la crittografia senza sale è insicura. Perché non sarebbe sicuro quando si utilizza già un IV casuale per ciascun valore? Penso che il commento potrebbe essere errato, ma è una gemma popolare, quindi non ne ero sicuro. Penso che stia trattando key in realtà come password e volevo solo verificarlo.

https://github.com/attr-encrypted/encryptor/blob/master/lib/encryptor.rb#L57

  if options[:iv]
    cipher.iv = options[:iv]
    if options[:salt].nil?
      # Use a non-salted cipher.
      # This behaviour is retained for backwards compatibility. This mode
      # is not secure and new deployments should use the :salt options
      # wherever possible.
      cipher.key = options[:key]
    else
      # Use an explicit salt (which can be persisted into a database on a
      # per-column basis, for example). This is the preferred (and more
      # secure) mode of operation.
      cipher.key = OpenSSL::PKCS5.pbkdf2_hmac_sha1(options[:key], options[:salt], 2000, cipher.key_len)
    end
  else
    cipher.pkcs5_keyivgen(options[:key])
  end

Ho intenzione di scrivere qualcosa da zero e utilizzare solo librerie di base. La mia chiave proviene da SecureRandom.base64(32) e la memorizzerò nel codice e Base64 la decodificherà per ottenere la chiave binaria e la userò per la crittografia/decodifica, insieme a IV casuali per ogni elemento di dati. Non penso di aver bisogno di un sale per quello. Vorrei confermare.

9
Chloe

Hai bisogno di entrambi un sale e un IV quando fai ... due distinte azioni, una che richiede un sale e l'altra un IV. Questo è il tuo caso qui.

Il sale si riferisce alla trasformazione di password in un chiave segreta. Questo è ciò che viene utilizzato nel tuo codice di esempio: PBKDF2 è una funzione di derivazione della chiave basata su password. Come tutto ciò che utilizza le password, PBKDF2 necessita di lentezza configurabile (questo è il parametro "2000") e anche unicità, che il sale concede. Questa è una sottocassa di hashing della password, che è spiegato lì .

L'IV è necessario per la crittografia effettiva. modalità CBC è un algoritmo sequenziale, in cui ogni blocco di dati viene prima XORed con l'output dell'elaborazione del blocco precedente. Deve iniziare da qualche parte ... quindi IV è il "blocco precedente" arbitrario da utilizzare per il primo blocco.

In generale, la modalità CBC richiede un IV che è uniformemente casuale e non può essere previsto da un utente malintenzionato in grado di scegliere parte dei dati che devono essere crittografati (l'attacco BEAST su SSL è di quel tipo). Tuttavia, i problemi sorgono solo quando si utilizza la stessa chiave almeno due volte. Pertanto, i seguenti trucchi possono essere applicabili ed evitare la necessità di trasmettere un IV lungo il file crittografato:

  • PBKDF2 può essere utilizzato per generare un output di lunghezza configurabile. È possibile generare con PBKDF2 abbastanza byte per la chiave e IV.
  • Viene utilizzato un IV fisso convenzionale (ad esempio "tutti zeri").

Entrambi i metodi sono validi solo se la chiave di crittografia specifica viene utilizzata una sola volta. Ciò significa che se si utilizza la stessa password per crittografare due file, è necessario generare un nuovo salt casuale per ciascun file. Questo implica che se la trasformazione da password a chiave è computazionalmente costosa (e dovrebbe essere) e molti file devono essere crittografati con la stessa password, il costo totale può diventare proibitivo.

Se lo stesso salt viene utilizzato per più file (con la stessa password) (*), la conseguenza è che la stessa chiave verrà utilizzata per tutti questi file, il che va bene ... purché ogni file ottenga anche il proprio IV. Quindi l'IV deve essere archiviato in qualche modo nell'intestazione del file. D'altra parte, se tutti i file usano lo stesso sale, allora forse puoi reciprocare lo spazio di archiviazione per quel sale?

Il metodo generico, sicuro consiste nell'utilizzare un IV casuale (generato da un PRNG crittograficamente forte) per ciascuno corsa di crittografia , indipendentemente da come è stata ottenuta la chiave. Ciò evita di fare ipotesi implicite sul processo di generazione delle chiavi e sulla frequenza con cui si verifica nel protocollo generale. Inoltre, ciò consente di reciprocare la trasformazione da password a chiave se molti file devono essere crittografati come processo batch con la "stessa password": purché ogni file ottenga il proprio IV casuale, la stessa chiave (derivata una volta dalla password, con one salt) può essere applicato in modo sicuro per tutti. Questo è in qualche modo ciò che accade in TLS (versione 1.1 e successive): all records in una data connessione viene crittografato con il stessa chiave, ma ogni record ottiene il proprio IV, e questo è sicuro (in TLS 1.0, ogni record ottiene il proprio IV copiandolo dalla fine del precedente record crittografato, che è vulnerabile a BEAST perché questi IV sono quindi predicable attraverso l'osservazione; in TLS 1.1+, ogni record ha un nuovo, specifico random IV).

(*) MAI riutilizzare un valore salt per password distinte. Mai.

14
Tom Leek

Hai capito bene. Il codice trovato include un errore di nomenclatura comune. inizialmente ho letto male il codice. Tom Leek è corretto. Il codice non si sta rovinando, ma piuttosto sta usando il sale mentre si esegue l'hashing e successivamente un IV durante la crittografia.

Molte persone confondono i termini "sale" e "vettore di inizializzazione". Servono allo stesso scopo, ma sono tecnicamente utilizzati in diverse operazioni. Salt viene utilizzato durante l'hash, IV durante la crittografia. In entrambi i casi, lo scopo è impedire che lo stesso input produca sempre lo stesso output aggiungendo un input casuale.

Se vedi "salt" nel contesto della crittografia, probabilmente significa IV. Se vedi IV nel contesto dell'hash, probabilmente è il sale.


È importante sottolineare che, durante la crittografia, è necessario proteggere IV. Esiste un tipo di attacco in cui un IV non protetto può essere utilizzato per apprendere i dati crittografati. BEAST (a meno che non stia ricordando male) è stato un esempio di tale attacco. Puoi ottenere questa protezione automaticamente usando GCM, XST o un paio di altre nuove modalità di crittografia. Se usi una modalità di crittografia precedente come CBC, dovrai proteggere tu stesso il IV con una firma o un HMAC.

8
atk