Quanto è sicuro il mio software per la crittografia dei file con AES-256?

Question

Quanto è sicuro il mio software per la crittografia dei file con AES-256?

#1 da (6 voti)

4

Sto lavorando a un progetto per creare software per la crittografia dei file con AES in Java, il suo funzionamento è abbastanza semplice, ma mi chiedevo se fosse davvero sicuro.

Il programma richiede all'utente una passphrase per crittografare il file selezionato, dopo aver inserito la passphrase, è protetto con una funzione di derivazione chiave PBKDF2 con Hmac-SHA256, sale è un generatore di numeri pseudocasuali su 8-byte SHA1 PRNG , le iterazioni sono 100.000 e la lunghezza della chiave è 256 bit.

La chiave sicura generata viene utilizzata per crittografare il file. Il vettore di inizializzazione per AES è un generatore di numeri pseudocasuali di 16 byte SHA1 PRNG , il file è ora crittografato.

I primi 16 byte del file crittografato vengono salvati nella IV e per gli ultimi 8 byte per memorizzare il sale di PBKDF2.

Salt e IV non sono crittografati insieme ai file, ma vengono aggiunti in seguito. Queste operazioni sono sicure?

java aes file-encryption sha256 pbkdf2

posta Thealexzava 02.03.2016 - 14:18

fonte

1 risposta

Leggi altre domande sui tag java aes file-encryption sha256 pbkdf2

Confronto tra chiavi OpenPGP presumibilmente identiche e pubblicate attraverso canali diversi Puoi mai ottenere dati parzialmente decrittografati da un algoritmo di decodifica?

score 6 · Accepted Answer

Primo: Si prega di non roll la propria crittografia.

Se lo fai per scopi di produzione, ti consiglio vivamente di non utilizzarlo. Se vuoi migliorare le tue capacità di programmazione o questo è un progetto di ricerca, non importa se non ti aspetti una strong sicurezza (professionale) da esso.

Ora ai punti reali che sono migliorabili su ciò che hai dato qui (in ordine di apparizione nel post):

PKCS # 5 PBKDF2 con HMAC - SHA-256 . Per favore. PBKDF2 è uno standard vecchio per derivazione basata su password e dovrebbe essere sostituito almeno da bcrypt o ancora meglio Argon2 . Vedi anche la nostra risposta canonica sull'hash della password .
100.000 iterazioni . Si prega di non hardcodificare il conteggio delle iterazioni ma piuttosto di trovarlo dinamicamente in fase di esecuzione a seconda di cosa può fare la CPU. Questo è particolarmente vero se non conosci la tua esatta piattaforma di destinazione e se il tuo software sarà in giro per qualche tempo. TrueCrypt è anche caduto su questo problema.
8 byte salt . Mentre un sale da 8 byte (= 64 bit) può andare bene, un sale da 16 byte (= 128 bit) è una scelta migliore, per prevenire attacchi pre-calcolo sull'intervallo limitato di sali.
SHA-1 -PRNG . Non hai fornito dettagli su questo. Sembra OK, ma dovresti eseguire l'aggiornamento se possibile (su SHA-256 o SHA-3 ), per evitare SHA -1 che è ancora OK per l'esecuzione di un PRNG, ma potrebbe far luce sul tuo strumento per l'utilizzo di un vecchio e " broken " algoritmo.
16 byte IV per AES . Nota che questa è la scelta appropriata per CBC, CFB, CTR, OFB, ... (vale a dire tutte le modalità di crittografia non autenticate ) di solito non è la scelta appropriata per le modalità di crittografia autenticate che richiedono un nonce di 12 byte per una sicurezza ottimale. Se si è in grado di garantire chiavi univoche (che sembra possibile), è possibile lasciare il valore predefinito nonce a zero.
AES / CBC / PKCS5Padding . Questa sarebbe una scelta OK (non una buona scelta!) Se avessi qualche mezzo per autenticare il messaggio (ad esempio, conferma che non è stato manomesso). Non è così, quindi la scelta migliore sarebbe quella di utilizzare uno schema di crittografia autenticato come AES-GCM , AES-CCM , AES-EAX , ...
I dati associati (sale + IV) . Innanzitutto, è possibile lasciare il valore predefinito di default su un valore (tutto zero?) Se i file rimangono piccoli (meno di 68 GB) e utilizzano AES-GCM. In secondo luogo, è necessario autenticare questi dati come "dati associati" e aggiungere un tag di autenticazione (in chiaro) alla fine del file (le librerie decenti lo faranno automaticamente). Se si dovesse utilizzare questo è così com'è, un utente malintenzionato (che conosce il primo blocco) potrebbe modificare l'IV per rendere l'utente legittimo decifrare un testo in chiaro della scelta dell'attaccante. Inoltre, si desidera aggiungere i parametri di derivazione della chiave (come i conteggi di iterazione, i parametri di tempo e spazio e altre configurazioni) ai dati associati per garantire l'adattabilità a lungo termine del formato.