26

What's the most popular command to do such things as encrypting a file or directory in terminal in Linux?

31

I think it would be gpg. The syntax for files and directories differs though.

Encryption

For files(outputs filename.gpg):

gpg -c filename

For dirs:

gpg-zip -c -o file.gpg dirname

Decryption

For files(outputs filename.gpg):

gpg filename.gpg

For dirs:

gpg-zip -d file.gpg

Edit: Corrected as @Mk12 pointed out the mistake of compression/decompression for encryption/decryption.

  • Shouldn't that be "Encryption" and "Decryption"? – mk12 Jul 27 '12 at 18:41
  • Nobody has said how to encrypt a directory. – chovy Oct 18 '14 at 8:50
  • 1
    @chovy Not that above it says: For dirs: gpg-zip -c -o file.gpg dirname – celebdor Oct 20 '14 at 10:33
  • @celebdor missed that one. thanks. edit: that doesn't work for me. I get some weird encrypted output when I decrypt the file. – chovy Oct 24 '14 at 15:29
  • @chovy: Sorry to hear that. I can confirm that encrypting and decrypting directories as shown above worked for me, using gpg-zip (GnuPG) 1.4.16 under Mint 17. – Michael Scheper Jun 12 '16 at 9:13
10
  • with openssl

openssl des3 -salt -in unencrypted-data.tar -out encrypted-data.tar.des3

Decrypt:

openssl des3 -d -salt -in encrypted-data.tar.des3 -out unencrypted-data.tar

  • encrypt with AES

aescrypt -e -p password file.jpg

Decrypt:

aescrypt -d -p password file.jpg.aes

  • 1
    +1 for showing how to do it with openssl, which is most likely available out-of-the-box. – DevSolar Aug 22 '12 at 15:39
  • Indeed, but 3DES is considered insecure and should not be used, AES (aescrypt) is a much better option, see: stackoverflow.com/questions/1619212/… – jmng Jul 24 '18 at 10:01
2

Try GnuPG.

To encrypt: gpg -c filename

To decrypt: gpg filename.gpg

2

This is my method using openssl and tar

Open Encrypted Directory:

openssl enc -aes-256-cbc -d -in ~/vault.tar.gz.dat | tar xz; thunar ~/vault

Lock Encrypted Directory:

tar cz vault/ | openssl enc -aes-256-cbc -out ~/vault.tar.gz.dat; rm -r ~/vault
  • 1
    rm -r does not delete data; it merely unlinks it. You'll need to use something like srm to erase the data from the disk. – jbindel May 19 '16 at 2:51
2

I personally use aescrypt mostly.

      aescrypt -e "File" 

and decrypt:

      aescrypt -d "File"

Or there's mcrypt:

      mcrypt "File" 

and decrypt:

      mcrypt -d "File"

And for a directory , I suggest tar'ing the dir, and encrypting that. Then after unencrypting, just untar the file:

      tar -cf "Dir.tar" Dir/

and to untar

      tar -xf "Dir.tar"
1

If highest level of security is not a big problem ( the man page of zip says, that the encryption algorithm used by zipfile utilities are weaker than PGP), then I prefer zip and unzip. It zips my directories and encrypts at the same time. I prefer zip because you can have a kind of incremental zip and encrypt instead of zipping and encrypting the whole thing again. Especially it is useful when the directory sizes are very large.

ZIP and encrypt

zip file.zip file
zip -r directory.zip directory
zip --encrypt file.zip.enc file # prompt for password
zip --encrypt -r directory.zip.enc directory # prompt for password

Unzip and decrypt

unzip directory.zip.enc #Beware if any directory is present with the same name as the zipped file, then it would be overwritten. Hence I normally send the contents to another directory.

unzip directory.zip.enc -d directory-new # prompts for password
0

May not be popular but I've been working on a project to encrypt/decrypt anything with minimal user interaction through the use of a few Bash scripts. Here's a link to the Hak5 post that explains setup for testing.

Cutting through the source code logics though here's what happens for each type of data that can be handled by the above linked project

_gnupg_encrypt_opts="--always-trust --armor --batch --encrypt --recipient user@host.domain"
 _bulk_output_dir="some_path"
_arbitrary_parsed_output="some_file.gpg"
## If file make encrypted time stamped file with similar name
_path_to_file="${_mapped_input}"
_path_to_output="${_bulk_output_dir}/$(date -u +%s)_${_path_to_file##*/}.gpg"
cat "${_path_to_file}" | gpg ${gpg _gnupg_encrypt_opts} > "${_path_to_output}"
## else if directory make compressed encrypted time stamped output file
_path_to_dir="${_mapped_input}"
_path_to_output="${_bulk_output_dir}/$(date -u +%s)_dir.tgz.gpg
tar -cz - "${_path_to_dir}" | gpg ${gpg _gnupg_encrypt_opts} > "${_path_to_output}"
## else if something else append encrypted output to file
_path_to_output="${_arbitrary_parsed_output}"
cat <<<"${_mapped_input}" | gpg ${gpg _gnupg_encrypt_opts} >> "${_path_to_output}"

The ${_mapped_input} variable is set by reading a mkfifo named pipe file and setting anything read to an array with mapfile -t _lines < "${_file_to_map}" which is later expanded and saved to a ${_mapped_input}... a bit convoluted but it allows for experimental features to act on individual lines. End results are you end up with a directory for holding encrypted files or compressed directories and a file with various packets of encrypted data.

Decryption for files or compressed directories is simple enough on a device with a private key related to the public key used for encryption. But decryption of multiple armor encrypted data packets was a bit tougher, so there a script named Paranoid_Pipes_Scenario_One.sh in the above project written to do it all with minimal user interaction. Below is a simplified version of the helper scripts source code for normal encrypted files and directories.

_gnupg_decrypt_opts="--quiet --no-tty --always-trust --passphrase-fd 9 --decrypt"
_decryption_output_dir="some_directory"
# if file
exec 9<"${_pass[@]}"
_path_to_file="${_mapped_input}"
_output_name="${_path_to_file##*/}"
_output_name="${_output_name%.gpg*}"
cat "${_path_to_file}" | gpg ${_gnupg_decrypt_opts} > "${_decryption_output_dir}/${_output_name}"
# else if compressed file
_path_to_file="${_mapped_input}"
_output_name="${_path_to_file##*/}"
_output_name="${_output_name%.tgz.gpg*}"
mkdir -p "${_decryption_output_dir}/${_output_name}"
_old_pwd="${PWD}"
cd "${_decryption_output_dir}/${_output_name}"
cat "${_path_to_file}" | gpg ${_gnupg_decrypt_opts} | tar -xzf -
cd "${_old_pwd}"
# else if non-compressed directory
_path_to_file="${_mapped_input}"
_output_name="${_path_to_file##*/}"
_output_name="${_output_name%.tar.gpg*}"
mkdir -p "${_decryption_output_dir}/${_output_name}"
_old_pwd="${PWD}"
cd "${_decryption_output_dir}/${_output_name}"
cat "${_path_to_file}" | gpg ${_gnupg_decrypt_opts} | tar -xf -
cd "${_old_pwd}"

If you wish to see what other features are working and tested in a publicly verifiable way, then check out the Travis-CI build logs (especially near the end of the logs) you'll find there's some other fancy things being worked on in relation to encryption and decryption of nearly any data.

0

Use FinalCrypt - Unbreakable One-Time Pad OpenSource File / Directory Encryption (GUI & CLI)

It creates One-Time Pad keys by itself

java -cp FinalCrypt.jar rdj/CLUI --encrypt --password-prompt -k My-Key-Directory/ -t My-Test-Directory/

Password:

Started encrypting 4 files totally 249,7 MiB

🔒 "/home/ron/My-Test-Directory/Video/Eerebegraafplaats.mp4.bit" 🗝 ✔ 🖆 ✔ 🔒✔ ℄✔ 🗑✔ SHA-256: "C1E3F3A3545FEA026F3FB344F3D0798B54820B7F9AD9AAC4BE9FD1E955F947DA"->"D53FCEADDF542AC3655B547778911F786C2C2BDD327E0618A9E7F77B57792DEA" 58,4% 🔒 "/home/ron/My-Test-Directory/Video/castle-waxjo-sweden.mp4.bit" 🗝 ✔ 🖆 ✔ 🔒✔ ℄✔ 🗑✔ SHA-256: "8AEFC9744143451F32B82BBAC6A4291BC76C747A6DA1EA024702AA51A966F810"->"323618B7ED12A1F92D8FFB306CEEC6DFFED6862B7BF3922902E8AED29DF57ECE" 91,2% 🔒 "/home/ron/My-Test-Directory/Brother_HL-2170W-usaeng_quick-setup.pdf.bit" 🗝 ✔ 🖆 ✔ 🔒✔ ℄✔ 🗑✔ SHA-256: "0858D2D5A8CF118D40B517CD4A1F8D31D9F5A21221F75BD764B5E363FC1431FE"->"266CE42027F891DECF109D7A9DD69E8B42C0E43D35E952BEB89F7C7EA2DBE92C" 95,7% 🔒 "/home/ron/My-Test-Directory/Brother dsmobile 700d_uke_usr.pdf.bit" 🗝 ✔ 🖆 ✔ 🔒✔ ℄✔ 🗑✔ SHA-256: "8D718D2F29EF05BEB347D6920B3BFF5269685421B428E8D3ADFF569F67A716E0"->"88A98D893B6D1E540039D3E9BC0B0C19B46A10A209967F3235D5DEEBF073EC1E" 100,0%

Finished encrypting [4 / 4] files totally [249,7 MiB / 249,7 MiB] in 7,3 seconds (average: 34,2 MiB/s)

java -cp FinalCrypt.jar rdj/CLUI --decrypt --password-prompt -k My-Key-Directory/ -t My-Test-Directory/

Password:

Started decrypting 4 files totally 124,9 MiB

🔓 "/home/ron/My-Test-Directory/Video/castle-waxjo-sweden.mp4" 🖃 ✔ 🔓✔ ℄✔ 🗑✔ SHA-256: "323618B7ED12A1F92D8FFB306CEEC6DFFED6862B7BF3922902E8AED29DF57ECE"->"8AEFC9744143451F32B82BBAC6A4291BC76C747A6DA1EA024702AA51A966F810" 32,8% 🔓 "/home/ron/My-Test-Directory/Video/Eerebegraafplaats.mp4" 🖃 ✔ 🔓✔ ℄✔ 🗑✔ SHA-256: "D53FCEADDF542AC3655B547778911F786C2C2BDD327E0618A9E7F77B57792DEA"->"C1E3F3A3545FEA026F3FB344F3D0798B54820B7F9AD9AAC4BE9FD1E955F947DA" 91,2% 🔓 "/home/ron/My-Test-Directory/Brother dsmobile 700d_uke_usr.pdf" 🖃 ✔ 🔓✔ ℄✔ 🗑✔ SHA-256: "88A98D893B6D1E540039D3E9BC0B0C19B46A10A209967F3235D5DEEBF073EC1E"->"8D718D2F29EF05BEB347D6920B3BFF5269685421B428E8D3ADFF569F67A716E0" 95,5% 🔓 "/home/ron/My-Test-Directory/Brother_HL-2170W-usaeng_quick-setup.pdf" 🖃 ✔ 🔓✔ ℄✔ 🗑✔ SHA-256: "266CE42027F891DECF109D7A9DD69E8B42C0E43D35E952BEB89F7C7EA2DBE92C"->"0858D2D5A8CF118D40B517CD4A1F8D31D9F5A21221F75BD764B5E363FC1431FE" 100,0%

Finished decrypting [4 / 4] files totally [124,9 MiB / 124,9 MiB] in 3,4 seconds (average: 36,3 MiB/s)

It also has a GUI

Just trying to help the community...

  • See Comments on FINALCRYPT. – Scott Jul 14 at 7:44
  • FinalCrypt 5 added Auto Key and creates OTP Keys automatically so the discussion Scott is referring to is no longer relevant – Ron de Jong Jul 14 at 10:38
  • I would like to see a description of how it works that’s more technical and less hand-waving. The issue is that one-time pads (1) are great for transmission of data, and lousy for storage, and (2) should be random. If FinalCrypt’s OTPs are truly random, then they must be stored, which compromises security. If they can be regenerated, then they are not random, but only pseudo-random, and so they are not proper OTPs.  … (Cont’d) – Scott Jul 14 at 15:18
  • (Cont’d) …  Their page on Auto Key Management indicates that the OTPs are stored “on a detachable external (USB) drive. ”  OK, that could work.  But, if you have to attach your USB drive every time you want to decrypt your file (and given that an OTP must be at least as big as the file it encrypts), you might as well just store your files on the removable drive and not bother with encryption.   … (Cont’d) – Scott Jul 14 at 15:18
  • (Cont’d) …  Also, the main FinalCrypt page says “most crypto software uses broken AES …”, but claims that AES is “broken” seem to be greatly exaggerated. Related: Why is AES considered to be secure? (on Cryptography Stack Exchange). – Scott Jul 14 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy