Crittografia sicura dei file con OpenSSL e un piccolo trucco?

0

Cerco di crittografare in modo sicuro un file con OpenSSL. Sono nuovo di OpenSSL e ho appena letto qui, che non è molto sicuro a causa del suo comportamento nel generare sale e amp; IV e memorizzarlo nel file crittografato.

Uso un server, dove OpenSSL è l'unico strumento disponibile per la crittografia dei file (attualmente ho V1.0.1t).

Diciamo che uso una password con 256 o più byte di dati casuali, inclusi tutti i tipi di caratteri speciali e aes-256-cbc per la crittografia.

Lo so, l'md5 di password + sale è ora memorizzato nei primi 32 byte del file enritto. Abbastanza debole finora ...

Che cosa succede se uso un piccolo trucco e leggo i primi 32 byte e li memorizzo in una posizione diversa (DB, ecc.). Quindi sovrascriverli nel file con dati casuali ... In seguito, per decrittografare, ho rimesso i byte originali nel file, prima di decodificare.

Per quanto ho capito, questo sarebbe un enorme aumento della sicurezza, a condizione che nessuno possa accedere ai frammenti memorizzati.

È corretto? Cosa ne pensi?

    
posta user3475261 10.10.2018 - 12:53
fonte

1 risposta

2

I know, the md5 of password + salt is stored in the first 32 bytes of the enrypted file now.

Questo non è vero. Scriverà solo il sale da 8 byte e nulla deriverà dalla password (non MD5, non qualcos'altro) come lei reclama. Invece il sale e la password saranno usati insieme per derivare la chiave di crittografia usando MD5, ma l'utente deve fornire la password per la decrittografia in modo che la chiave di crittografia possa essere nuovamente derivata dalla password (data) e dal sale memorizzato.

Il problema con enc è invece che MD5 è una funzione di derivazione della chiave debole perché è le password troppo veloci e quindi più semplici possono essere forzate brute. Vedi anche openssl enc usa md5 in hash la password e il sale .

Se hai davvero bisogno di usare enc usa una password difficile in modo che la forzatura bruta non abbia successo.

Let´s say, I use a password with 256 or more bytes of random data,...

Sì, probabilmente è abbastanza difficile: 2048 bit di dati casuali possono essere ben considerati impossibili da forzare brute, comunemente anche 128 o 256 bit (16 o 32 byte binari casuali o circa 22..44 alfanumerici casuali caratteri) sono considerati sufficienti.

    
risposta data 10.10.2018 - 13:56
fonte

Leggi altre domande sui tag