È sicuro usare un prefisso univoco per ogni set di dati, invece di usare IV (in AES)?

4

In continua alla mia domanda qui: Come impedire all'utente di indovinare la chiave (password), se ha accesso a tutti i dati (eccetto la chiave)

Ho pensato, invece di usare il campo IV sepolto per ogni SSN (per esempio). Posso usare un prefisso per questo.

Ad esempio, invece di encrpyt {{ssn}} , criptico: {{user_id:ssn}} Ogni utente ha un ID univoco. Quindi nessuno può trovare la duplicazione nel database.

La mia domanda è: se ogni volta che crittografo i dati, sto usando, un prefisso uniuqe ai dati. È vero, che non ho bisogno di usare IV?

    
posta Aminadav Glickshtein 17.11.2016 - 14:02
fonte

2 risposte

2

Nel tuo caso, correggere. Non hai bisogno di un IV casuale. La combinazione di user_id , ssn e la tua chiave è globalmente unica, quindi l'utente malintenzionato non sarà in grado di trovare duplicati da un algoritmo sicuro. (vale a dire AES-128 o superiore)

Modifica: gli IV dovrebbero sempre essere casuali. Mentre nel caso dell'OP, potrebbe non essere così importante, di solito è, ed è facile da implementare, quindi usa IV casuali. Vedi commenti.

Vale la pena notare che non si sta utilizzando un algoritmo di concatenamento perché la quantità di dati che si sta crittografando è così piccola. Questo riduce ciò di cui ti devi preoccupare. Lo scopo dell'IV è quello di assicurarsi che il primo 'blocco' sia unico, e lo scopo del metodo di concatenamento è di far apparire i blocchi rimanenti casuali in modo che non ci sia pattern riconoscibile nei dati lunghi.

Ma i dati si inseriscono in un blocco (128 bit per AES-128), quindi non è necessario.

    
risposta data 17.11.2016 - 14:48
fonte
2

Questa domanda non può essere risolta senza sapere quale cifra o modalità è in uso, perché quelli diversi hanno requisiti diversi sui loro IV e diverse modalità di errore. Ci sono due casi generali qui:

  1. Cipher che richiedono IVs unici .
    • AES-CTR è un ottimo esempio. La modalità di errore per il riutilizzo IV qui è perdita di riservatezza catastrofica : un utente malintenzionato potrebbe probabilmente riuscire a decrittografare tutti i valori.
  2. Cipher che richiedono IVs casuali .
    • AES-CBC è un ottimo esempio. La modalità di errore per il riutilizzo IV è perdita di sicurezza semantica - il testo in chiaro crittografato due volte produce lo stesso testo cifrato, quindi l'autore dell'attacco può dire che lo stesso testo cifrato in due contesti diversi sta per lo stesso testo in chiaro.

Quindi, chiaramente, se stai usando qualcosa come AES-CTR devi utilizzare IV esclusivi, non c'è modo di aggirarlo. Più in generale, devi seguire le istruzioni per i codici specifici che stai utilizzando, cosa che non hai nemmeno detto, invece di provare a inventare un modo ad hoc di non farlo. (Dovrebbe essere una enorme bandiera rossa!)

In secondo luogo, stai giocando veloce e libero con l'idea che stai usando un prefisso "unico", perché stai descrivendo questo prefisso come user_id . Ma ciò implica che i prefissi che hai in mente sono unici per ogni utente . Ma ciò che normalmente vorrebbero utilizzare è un IV che è unico per ogni operazione di crittografia se si crittografa due volte lo stesso testo in chiaro, ci si aspetta che fornisca due IV diversi in modo che le crittografie producano diversi testi cifrati.

In terzo luogo, le tue preoccupazioni sulla "duplicazione" sono sulla strada sbagliata. A seconda di cosa intendi con quello (che non è chiaro!):

  • Se si usano gli IV casuali e li si antepone al testo in chiaro, non possono esserci duplicati di cifratura affatto , poiché le crittografie sono iniettive - ogni cifratura può essere "annullata" e hai la certezza di riavere il testo in chiaro originale. Ciò implica che coppie duplicate (IV, testo cifrato) sono impossibili.
  • Se sei preoccupato che la crittografia dello stesso testo in chiaro due volte in contesti diversi produrrà dei ciphertex "duplicati", la tua proposta di prefissare user_id non lo risolverà! Crittografare lo stesso {{user_id:ssn}} plaintext due volte produrrà sempre lo stesso testo cifrato.

L'ho detto in la mia risposta alla tua altra domanda recente , e la ripeto: non devi andare avanti con i tuoi piani per implementare la sicurezza per la tua applicazione. Hai bisogno di aiuto professionale e competente.

    
risposta data 17.11.2016 - 23:43
fonte

Leggi altre domande sui tag