Normalmente userei PBKDF2 per generare una chiave che utilizzerei con AES. Ma visto che l'hash sarà lungo quanto i dati che ho bisogno di crittografare c'è qualche svantaggio solo a XOR'ing?
Il mio ragionamento è che se riesci a ricavare l'hash, avresti comunque il tasto AES.
* Solo per aggiungere il motivo per cui utilizzerei PBKDF2 è necessario utilizzare una password fornita dall'utente. I dati crittografati possono essere considerati casuali. Sto salendo anche io.
Usando PBKDF2 in questo modo, ciò che stai facendo in realtà sta trasformando PBKDF2 in una codifica stream . I tre problemi principali con questa idea sono:
L'uso di PBKDF2 come codice di flusso non è stato studiato a fondo. Potrebbe andare bene O no. Le proprietà di sicurezza di PBKDF2 sono state analizzate solo per la maggior parte delle uscite corte e quindi solo come KDF.
Se riutilizzi la stessa password e salt, otterrai lo stesso risultato. In una modalità XOR-con-i-dati del flusso, questo è molto brutto se si criptano due elementi. In questo senso, ora hai unito il sale PBKDF2 a quello che era l'IV per AES, quindi confondendo i requisiti. Faresti meglio ad assicurarti che il tuo protocollo generale operi correttamente con quello. (In questo senso, è simile all'utilizzo di PBKDF2 per generare una chiave per la crittografia RC4, perché RC4 non ha IV.)
PBKDF2 è lento con iterazioni. Accade così che la sua velocità di elaborazione sia anche proporzionale alla lunghezza di output richiesta. Se usi PBKDF2 / SHA-1 e chiedi, per esempio 24 byte, e usi 10000 iterazioni, pagherai effettivamente per 20000 iterazioni. Questo può diventare rapidamente intollerabile per i messaggi più lunghi da crittografare. Prendi nota che l'autore dell'attacco che esegue un attacco di dizionario non ha bisogno di calcolare l'intero stream; quindi, si incorre nel rischio di rallentare inutilmente il difensore mentre si lascia correre l'attaccante a tutta velocità.
Sì. A causa di attacchi con testo in chiaro noto, un avversario che può trovare il testo in chiaro, potrebbe usarlo per scoprire l'hash per decifrare i testi cifrati a cui l'avversario non ha il testo in chiaro.
AES è stato appositamente creato per impedire a un utente malintenzionato di scoprire la chiave, anche se conosce sia il testo in chiaro che il testo cifrato.
Se vuoi ottenere prestazioni e utilizzare ancora XOR, sarebbe opportuno aggiungere caratteri casuali alla password e quindi includere questi caratteri con il messaggio.
Ad esempio, per crittografare M, si genera un nonce casuale N. Quindi usi: PBKDF2 (Password + N) xor M = C
Invia NC al destinatario
NC viene decodificato selezionando il nonce, quindi il destinatario fornisce la password pre-condivisa, quindi
PBKDF2 (Password + N) xor C = M.
Per scoprire la chiave per un messaggio crittografato con XOR + PBKDF2 (Password + A) e avere un testo in chiaro e un testo cifrato appartenente a PBKDF2 (Password + N), avrebbe comunque dovuto craccare il PBKDF2 usando la bruteforce semplice.
Non c'è motivo per cui questa costruzione debba essere insicura, tranne che per gli attacchi standard plain-plain e ciphertext. Per evitare quelli hai ancora bisogno di un meccanismo di autenticazione. (come AES-GCM o Poly-1305).
Come costruzione pratica ti suggerirei di usare un offset. Quindi useresti i primi bit del PBKDF per ricavare una chiave per l'autenticazione e il resto come pad.
Dovresti quindi utilizzare, ad esempio, HMAC-SHA256 per autenticare il testo cifrato e aggiungere il tag.
Funziona solo nel caso in cui si conoscano le dimensioni dei dati prima di eseguire la derivazione della password. Questo è il motivo per cui non è ampiamente utilizzato.
Perché è sicuro?
Sto saltando la parte di autenticazione qui perché questo è standard per i codici di flusso.
Fondamentalmente PBKDF è una chiamata ripetuta a HMAC, che è un PRF, quindi se il tuo sale è casuale (è il tuo IV qui) l'output è pseudocasuale e dovrebbe essere sicuro come HMAC.
Leggi altre domande sui tag encryption hash