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

Naviga le tue risposte
8

Stavo guardando questo codice e ho trovato questi commenti che dicono che la crittografia senza sale è insicura. Perché sarebbe insicuro quando stai già utilizzando una IV casuale per ogni valore? Penso che il commento potrebbe essere errato, ma è una gemma popolare quindi non ero sicuro. Penso che stia trattando key proprio come password , e volevo solo verificare.

link 

  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 le 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 / decrittografia, insieme a IV casuali per ogni elemento di dati. Non penso di aver bisogno di un sale per quello. Vorrei confermare.

    
posta Chloe 03.01.2014 - 04:41
fonte

2 risposte

13

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

Salt si riferisce alla conversione di una password in una chiave segreta . Questo è ciò che viene utilizzato nel codice di esempio: PBKDF2 è una funzione di derivazione della chiave basata su password . Come tutto ciò che utilizza le password, PBKDF2 richiede lentezza configurabile (che è il parametro "2000") e anche unicità , che il sale garantisce. Questa è una sottoclasse di hashing delle password, che è spiegato lì .

L'IV è necessario per la crittografia effettiva. La modalità CBC è un algoritmo sequenziale, in cui ogni blocco di dati viene prima sottoposto a XOR 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 che si trova nella posizione di scegliere parte dei dati che deve essere crittografato (l'attacco BEAST su SSL è di quel tipo). Tuttavia, i problemi sorgono solo quando viene utilizzata la stessa chiave almeno due volte. Pertanto, i due trucchi seguenti potrebbero essere applicabili ed evitare la necessità di trasmettere una 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 utilizzata una IV convenzionale, fissa (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 viene utilizzata la stessa password per crittografare due file, è necessario generare un nuovo sale casuale per ciascun file. Questo implica che se la trasformazione password-chiave è computazionalmente costosa (e dovrebbe essere) e molti file devono essere crittografati con la stessa password, allora il costo totale può diventare proibitivo.

Se lo stesso sale è usato per diversi file (con la stessa password) (*), la conseguenza è che la stessa chiave verrà usata per tutti questi file, il che va bene .. fino a quando ogni file ottiene anche il proprio IV. Quindi l'IV deve essere memorizzato in qualche modo nell'intestazione del file. D'altra parte, se tutti i file utilizzano la stessa quantità di sale, allora forse puoi condividere lo spazio di archiviazione per quel sale?

Il metodo generico, sicuro consiste nell'utilizzare un IV casuale (generato da un PRNG crittograficamente valido) per l'esecuzione della crittografia ogni , 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, questo consente di mutualizzare la trasformazione password-to-key se molti file devono essere crittografati come un processo batch con la "stessa password": purché ogni file abbia il proprio IV casuale, la stessa chiave (derivata una volta dalla password, con one salt) può essere tranquillamente applicato per tutti. Questo è in qualche modo ciò che accade in TLS (versione 1.1 e altro): tutti i record in un dato la connessione viene crittografata con la 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 è quindi prevedibile attraverso l'osservazione; in TLS 1.1+, ogni record ha un nuovo IV casuale specifico).

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

    
risposta data 03.01.2014 - 14:36
fonte
8

Hai capito bene. Il codice che hai trovato include un errore di nomenclatura comune. in origine ho interpretato erroneamente il codice. Tom Leek ha ragione. Il codice non sta fallendo, ma sta usando il sale mentre si esegue l'hashing e poi si utilizza un IV durante la crittografia.

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

Se vedi "sale" nel contesto della crittografia, probabilmente significa IV. Se vedi IV in contesto di hashing, probabilmente è il sale.

È importante sottolineare che, durante la crittografia, è necessario proteggere l'IV. Esiste un tipo di attacco in cui una IV non protetta può essere utilizzata per apprendere i dati crittografati. LA BESTIA (a meno che non mi stia ricordando male) è stato un esempio di un simile attacco. Puoi ottenere questa protezione automaticamente utilizzando GCM, XST o altre due modalità di crittografia più recenti. Se si utilizza una modalità di crittografia meno recente come CBC, sarà necessario proteggere la IV da soli con una firma o un HMAC.

    
risposta data 03.01.2014 - 04:47
fonte

Leggi altre domande sui tag

Realizzazione di una demo sulle reti wireless aperte che sfruttano con Firesheep Cosa succede quando si esegue la crittografia con la chiave privata? [duplicare]