Openssl Aes-Encryption Lossy?

Come per la riga di comando aes-encrypt , sono in grado di utilizzare questo come un modo affidabile per il backup?

Sono su Os X tra parentesi.

Cosa ho provato:

zip -er ./test.zip ./test # zip w/ password

Aggiunto questo al mio .bash_profile

#$1 == input file
#$2 == output file
aesenc ()
{
        openssl enc -aes-256-cbc -salt -in "$1" -out "$2"
}

#$1 == enc file
#$2 == out file
aesdecr ()
{
        openssl enc -d -aes-256-cbc -in "$1" -out "$2"
}

aesenc test.zip test.zip.enc aesdecr test.zip.enc test.zip

Ho controllato i file e tutto sembra andare bene in superficie.

Volevo solo sapere se qualcuno ne sapesse di più?

Penso che intendi la compressione con perdita come un jpeg, la perdita con perdita perde irreversibilmente dati, la compressione con perdita sarebbe terribile per i dati in generale e funziona solo con le immagini perché l'immagine sembra ancora "abbastanza buona" anche dopo aver perso i dati.

Il comando enc di Openssl non è "lossy", quindi dovrebbe essere affidabile per i dati ... ma IMO che utilizza un programma con una cronologia più lunga e una migliore gestione delle chiavi, come gpg / pgp, sarebbe meglio per backup crittografati sicuri. È raccomandato da Mr.Edward Snowden ed è relativamente "a prova di governo", e almeno in passato ho letto alcune cose sull'enc di openssl che riguardano.

Vedi questa domanda OpenSSL vs GPG per la crittografia dei backup off-site? per maggiori informazioni, come:

da questo post su security.stackexchange.com (da gennaio 2013) e da un altro utente di reputazione 159K, il openssl enccomando potrebbe lasciare qualcosa a desiderare:

Il formato di crittografia utilizzato da OpenSSL non è standard: è "ciò che fa OpenSSL" e se tutte le versioni di OpenSSL tendono a concordare tra loro, non esiste ancora alcun documento di riferimento che descriva questo formato tranne il codice sorgente OpenSSL. Il formato dell'intestazione è piuttosto semplice:

valore magico (8 byte): i byte 53 61 6c 74 65 64 5f 5f valore salato (8 byte)

Da qui un'intestazione fissa a 16 byte, che inizia con la codifica ASCII della stringa "Salted__", seguita dal salt stesso. È tutto ! Nessuna indicazione dell'algoritmo di crittografia; dovresti tenerne traccia tu stesso.

Il processo mediante il quale password e salt vengono trasformati nella chiave e IV non è documentato, ma uno sguardo al codice sorgente mostra che chiama la funzione EVP_BytesToKey () specifica di OpenSSL , che utilizza una funzione di derivazione della chiave personalizzata con alcuni hashing ripetuti . Questo è un costrutto non standard e non ben controllato (!) Che si basa sulla funzione hash MD5 di dubbia reputazione (!!); quella funzione può essere cambiata dalla riga di comando con il flag non documentato -md (!!!); il "conteggio delle iterazioni" è impostato dal enccomando su 1 e non può essere modificato (!!!!). Ciò significa che i primi 16 byte della chiave saranno uguali a MD5 (password || salt) , e basta.

Questo è abbastanza debole! Chiunque sappia scrivere codice su un PC può provare a decifrare un tale schema e sarà in grado di "provare" diverse decine di milioni di potenziali password al secondo (centinaia di milioni saranno raggiungibili con una GPU). Se usi "openssl enc", assicurati che la tua password abbia un'entropia molto alta! (vale a dire più alto del solito raccomandato; mira almeno a 80 bit). O, preferibilmente, non usarlo affatto; invece, cerca qualcosa di più robusto ( GnuPG , quando esegue una crittografia simmetrica per una password, usa un KDF più forte con molte iterazioni della funzione hash sottostante).

man enc ha anche questo sotto "BUGS":

Dovrebbe esserci un'opzione per consentire l'inclusione di un conteggio delle iterazioni.