Lunghezza dell'output di crittografia AES Java

1

Sto tentando di crittografare alcune colonne del database (valori stringa) utilizzando l'algoritmo AES Java. Questo è per proteggere determinati dati sensibili. Per alcuni utenti questi dati dovrebbero essere decodificati.

Nella crittografia AES Java, se la lunghezza del mio carattere di input è 60, la lunghezza della stringa crittografata diventa 88.

Ma non voglio modificare la lunghezza dei dati crittografati. Abbiamo una grande quantità di tavoli e molte applicazioni usano queste tabelle. Vogliamo ridurre al minimo l'impatto della crittografia di determinati campi nelle tabelle.

C'è qualche soluzione raccomandata? O c'è qualche algoritmo consigliato, esempio di codice, ecc.

Grazie, Prabakaran N

    
posta Prabakaran 28.05.2014 - 12:33
fonte

3 risposte

1

Quanto descritto nella domanda è Crittografia di conservazione dei formati . Tuttavia, aspettati una curva di apprendimento ripida e una grave mancanza di implementazioni già pronte.

    
risposta data 22.06.2014 - 19:34
fonte
0

A seconda della sicurezza che si sta tentando di raggiungere, ciò potrebbe non essere possibile: una certa quantità di espansione dell'output è necessaria per fornire protezione contro determinati attacchi.

Considerare il caso di un database che memorizza i record sanitari sotto forma di un elenco di malattie di cui una persona è affetta; inoltre, considera che "alta pressione sanguigna" crittografa a 0x1234abcd usando "semplice" AES (o qualsiasi cifra a blocchi) in Modalità BCE . (La BCE ha altri problemi oltre a essere deterministica, ma mi concentrerò su questo aspetto qui.)

Un utente malintenzionato potrebbe non conoscere il significato di 0x1234abcd, ma può facilmente identificare tutti i pazienti che condividono quel record!

Gli attacchi più elaborati sono possibili se l'attaccante ha accesso in scrittura al database: potrebbero, ad esempio, inserire malattie casuali, esaminare i corrispondenti numeri cifrati e costruire una tabella con corrispondenze di testo in chiaro in chiaro.

Questo è il motivo per cui i cifrari a blocchi vengono utilizzati quasi esclusivamente in una modalità di funzionamento che espande l'input di una certa lunghezza: L'espansione è (tra le altre cose) necessaria per consentire la crittografia di più messaggi con una sola chiave.

A seconda del contenuto del tuo database, l'attacco menzionato potrebbe o potrebbe non essere un problema, ma nella stragrande maggioranza di tutte le applicazioni, è preferibile che ECB usi un CCA-secure cryptosystem, che è necessariamente probabilistico, e quindi anche esteso in lunghezza.

    
risposta data 22.06.2014 - 19:48
fonte
0

Potresti prendere in considerazione l'uso di un codice in modalità CTR, che in pratica lo trasforma in un codice di flusso. La lunghezza di output dovrebbe essere uguale alla lunghezza di input, ma è comunque necessario creare un nonce univoco per ogni record. Se si dispone di un identificativo univoco per ciascun record, è possibile utilizzarlo per generare il nonce per il contatore. Fai attenzione: usare lo stesso nonce due volte con la stessa chiave consente a un utente malintenzionato di banalmente di recuperare il testo in chiaro.

    
risposta data 23.06.2014 - 03:00
fonte

Leggi altre domande sui tag