I wish to encrypt potentially gigabytes of data on my pc, and I wish to be able to decrypt and use those files.

However, I am a noob, so bear with me.

My idea is to use openSSL to encrypt files with AES-256bit-CTR, since it's fast.

I imagine I'd be using a super long password (at least 20 chars), I'd use the same salt and password for every individual file for speed.

My questions are:

  1. How to make my encrypted files as secure as possible? What arguments to provide in OpenSSL?
  2. Would I be safe if I were to use a 20-30 letter password?
  3. How to use a random IV? What argument to provide in openssl? (AFAIK openssl derives an IV based on the password, so if the pw is secure am I good?)
  4. What should my openssl command look like for max security? This is mine right now:

    openssl.exe enc -in secret.txt -e -aes-256-ctr -out something.txt -k securepass -salt
  • 1
    $\begingroup$ I'm voting to close this question as off-topic because this is about command line usage of OpenSSL, try superuser instead. $\endgroup$ – Maarten Bodewes Oct 25 '18 at 23:27
  • $\begingroup$ Note that to my knowledge OpenSSL calculates the key and IV from the password and salt, making above construction completely insecure. IV values are not allowed to repeat, especially not for CTR mode. Better keep the salt random. Oh, and you get about 4.7 bits of security per upper or lowercase character or 5.7 bits of security if you allow upper / lowercase characters to mix. That is if they are completely randomly selected. $\endgroup$ – Maarten Bodewes Oct 25 '18 at 23:35
  • $\begingroup$ @MaartenBodewes: by default yes enc derives key and IV if needed from pw and salt if any; IV can be overridden but isn't here. The command shown does use random salt (stored in encrypted file) in spite of OP's text saying otherwise -- but 64 bits of salt, per PKCS5v1 circa 1993, which means birthday bound about 4 billion invocations. And if OpenSSL version is <=1.0.2 (supported upstream for another year, and undoubtedly longer by stable distros) KDF defaults to MD5 so if you have more than 128 bits entropy in pw it is thrown away. (If less, ONE ITERATION provides no stretching.) ... $\endgroup$ – dave_thompson_085 Oct 26 '18 at 1:04
  • $\begingroup$ ... Of course humans can't remember 20 fully-random characters, so either the password is actually weak (and not helped by the abysmal KDF, as above) or stored somewhere (which becomes the weak point for attack). Not to mention the vulnerability of passing it as a commandline argument. $\endgroup$ – dave_thompson_085 Oct 26 '18 at 1:06

Browse other questions tagged or ask your own question.