8

I've been using this command to encrypt files for a while now:

openssl aes-256-cbc -a -salt -in secrets.txt -out secrets.txt.enc

Then I type in a password.

Can someone tell me, roughly speaking, how hard it would be to crack this?

I see that it's using salt, but that shouldn't really improve security much unless you're actually storing the hashed password somewhere (like a database of website logins), right? As I said I'm just encrypting files locally, typing in my password manually each time.

I also understand that openssl only uses one iteration to generate the IV so I guess this is not a very time-consuming process! Correct me if I'm wrong please.

In your estimation, how secure is this really?

Bonus question: What if I SHA1 hash the password first?

echo -n "mypassword" |openssl sha1

and paste in the SHA1 hash when encrypting files? I know this reduces security, because now the cracker knows the format of the password for sure (SHA1 hashes), but how much do you reckon this reduces security in practice? Would it be feasible to loop through all (or enough of) the SHA1 hashes?

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
user21203
  • 273
  • 1
  • 5
  • 11

3 Answers3

13

See the end of this answer: what OpenSSL does to convert the passphrase into an encryption key and IV is weak, because it is just a couple invocations of MD5, which is not slow enough. There is no way to simply change that within OpenSSL (no appropriate command-line option, this is hardcoded).

Pre-hashing you passphrase would not change things much. Doing a lot of nested hashing would enhance things a bit, but not to ideal levels since the salt would not be taken into account until the very last steps (a lot of shareable precomputations would still be doable by the attacker). Password hashing, with configurable slowness and salts, is not something which tolerates improvisation. At that point, it is much safer and simpler to ditch OpenSSL altogether, and use a better tool. I suggest GnuPG: the command-line tool, with its -c flag, does password-based symmetric encryption, and does it much better than openssl enc.

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 6
    OpenSSL is great _as a library_. The algorithm implementations are good. But the command-line tool should be used for debug tasks only. – Thomas Pornin Feb 25 '13 at 16:23
  • Ok, but what about running many iterations of PBKDF2 on the password *before* using the command-line tool? Would that in your opinion provide enough security? If so, how many iterations would you recommend? 100,000? Million? – user21203 Feb 25 '13 at 16:24
  • If you use PBKDF2, take care to use a non-fixed salt. For the iteration count, the answer is always: as high as you can tolerate. More iterations make usage slower for both you and the attacker. – Thomas Pornin Feb 25 '13 at 16:26
  • But a non-fixed salt is only really relevant if we are talking about the same password for many files? But for one encrypted file that we want to crack, how would a non-fixed salt make things any harder? – user21203 Feb 25 '13 at 18:58
  • I also hated the insecurity of the openssl enc hashing. So 10 years ago I created a script to do the equivalent of iterative hashing. http://www.ict.griffith.edu.au/anthony/software/#encrypt – anthony Feb 07 '19 at 05:57
3

The security of that command is directly relqted to how secure the password you pick is. As of right now aes-256-cbc isnt breakable so you can rely on some only being able to get the data from it by knowing the password.

Hashing the password will make very little difference. password hashes are used to hide the password so that even if someone got the stored password, they still wouldnt know the users password. This is completely irrelevant to encrypted files. The only benefit would be that that they will make your passphrase 40 characters long, however it would only be alpha characters of one casing and numbers. If anyone knew that it would reduce the time to crack it by a very significant amount. The benefit of using a kdf like pbkdf2 is so that it takes longer to bruteforce matching a password to a hash. So even if it was useful to use a hash at some point it would be easier to just bruteforce every possible hash instead of computing the hash. The better method is to just pick a password that would take a long time to crack.

What you should do is use zxcvbn to pick a good password and use that. Currently the worlds fastest password cracking computer can do 350 billion passwords a second, so having a 20+ character passphrase plus using zxcvbn to ensure it cant be cracked with something like a dictionary attack will ensure that your file wont be able to be cracked within the next millennia even if they have a thousand of these computers.

Eric
  • 451
  • 2
  • 4
1

Previous versions of openssl used a very weak key derivation process to derive an encryption key from the password, as stated in the other answers. However, version 1.1.1 of openssl now supports key derivation using PBKDF2, with a randomly generated salt and multiple iterations (10,000 by default) of sha256 hashing.

To encrypt a file using aes-256-cbc, with a password:

 openssl enc aes-256-cbc -e -salt -pbkdf2 -iter 10000 -in plaintextfilename -out encryptedfilename

To decrypt:

 openssl enc aes-256-cbc -d -salt -pbkdf2 -iter 10000 -in encryptedfilename -out plaintextfilename

See https://www.openssl.org/docs/man1.1.1/man1/openssl-enc.html for more info. Also, an equivalent/compatible implementation in javascript (using the web crypto api) can be found at https://github.com/meixler/web-browser-based-file-encryption-decryption.

mti2935
  • 19,868
  • 2
  • 45
  • 64