4 ms·

From your "how to use" page: # echo mysupersecretkey > /backups/key # openssl enc -aes-256-cbc -salt -in fullbackup.tar.gz \ -out fullbackup.ta

From your "how to use" page: # echo mysupersecretkey > /backups/key # openssl enc -aes-256-cbc -salt -in fullbackup.tar.gz \ -out fullbackup.tar.gz.enc -pass file:/backups/key Please don't do this. openssl -aes-256-cbc is not a strong key derivation algorithm, so you need to use keys with much higher entropy (dd if=/dev/random of=/backups/key); an attacker can run through a dictionary of common passwords ridiculously quickly, thousands of times faster than when you're using a proper key derivation algorithm, e.g. bcrypt/scrypt/PBKDF2 to generate the key. If you do want to derive it from something akin to a password. More seriously, openssl -aes-256-cbc does not do any integrity protection; in fact, an attacker can more or less flip any bits of his choosing in the ciphertext to flip those same bits in the plaintext. (Yes, I'm aware it's a tiny bit more complicated than that.) It is possible to fix both of the above, but may I recommend gpg --symmetric as a simple and reasonably secure alternative?

nanch 14y ago
Great feedback, I'll change the "how to" ASAP after some reading on the subject. Is there a secure command option that I can use with openssl instead of -aes-256-cbc? I originally tried to provide an example for openssl and gpg, but the gpg example ended up with a dependency on X11 via a dependency on pinentry so I took it out for simplicity.
- JoachimSchipper 14y ago
  OpenSSL sadly does not offer any authenticated encryption modes, so you cannot just replace -aes-256-cbc by something and be secure. There are basically two things that work: either authenticate the ciphertext [1] by having the user store a secure hash of each archive ("openssl sha512"), or switch to public-key crypto. Since the first is just inviting disaster - users aren't actually going to verify hashes - I recommend the second option. It's possible to build this on top of "openssl pkeyutl", but gpg is a lot nicer. If I were you, I'd just use gpg - some OSes/distros may pull in lots of stuff, but requiring a running (as opposed to installed) X server to run gpg is incredibly unlikely. [1] Always authenticate the ciphertext, never (just) the plaintext. See "padding oracle attack" for one practical reason why - getting a recognizable error when decrypting mangled ciphertext allows one to fully recover the plaintext. "Recognizable error" includes timing information. Just make sure you always authenticate the ciphertext.

nanch 14y ago

Great feedback, I'll change the "how to" ASAP after some reading on the subject. Is there a secure command option that I can use with openssl instead of -aes-256-cbc? I originally tried to provide an example for openssl and gpg, but the gpg example ended up with a dependency on X11 via a dependency on pinentry so I took it out for simplicity.

JoachimSchipper 14y ago
OpenSSL sadly does not offer any authenticated encryption modes, so you cannot just replace -aes-256-cbc by something and be secure. There are basically two things that work: either authenticate the ciphertext [1] by having the user store a secure hash of each archive ("openssl sha512"), or switch to public-key crypto. Since the first is just inviting disaster - users aren't actually going to verify hashes - I recommend the second option. It's possible to build this on top of "openssl pkeyutl", but gpg is a lot nicer. If I were you, I'd just use gpg - some OSes/distros may pull in lots of stuff, but requiring a running (as opposed to installed) X server to run gpg is incredibly unlikely. [1] Always authenticate the ciphertext, never (just) the plaintext. See "padding oracle attack" for one practical reason why - getting a recognizable error when decrypting mangled ciphertext allows one to fully recover the plaintext. "Recognizable error" includes timing information. Just make sure you always authenticate the ciphertext.