26
10
What's the most popular command to do such things as encrypting a file or directory in terminal in Linux?
26
10
What's the most popular command to do such things as encrypting a file or directory in terminal in Linux?
32
I think it would be gpg. The syntax for files and directories differs though.
For files(outputs filename.gpg):
gpg -c filename
For dirs:
gpg-zip -c -o file.gpg dirname
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.
10
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
aescrypt -e -p password file.jpg
Decrypt:
aescrypt -d -p password file.jpg.aes
Indeed, but 3DES is considered insecure and should not be used, AES (aescrypt) is a much better option, see: https://stackoverflow.com/questions/1619212/is-des-or-3des-still-being-used-today#1619237
– jmng – 2018-07-24T10:01:36.1331+1 for showing how to do it with openssl, which is most likely available out-of-the-box. – DevSolar – 2012-08-22T15:39:48.927
2
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"
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
1rm -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 – 2016-05-19T02:51:51.087
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
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)
Just trying to help the community...
FinalCrypt 5 added Auto Key and creates OTP Keys automatically so the discussion Scott is referring to is no longer relevant – Ron de Jong – 2019-07-14T10:38:28.167
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 – 2019-07-14T15:18:41.397
(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 – 2019-07-14T15:18:43.617(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 – 2019-07-14T15:18:45.460For a more technical description you can always read FinalCrypt's sourcecode http://www.finalcrypt.org/downloads/other/finalcrypt_sourcecode.zip
– Ron de Jong – 2019-07-15T22:23:11.403Attaching a drive with unencrypted files allows spyware to bulk-read all your files as soon as you attach. This is why you should never attach all your personal files unencrypted and only temporary decrypt the files you need to open. These days USB storage is small, but large in capacity so it's just a little USB key and FinalCrypt automatically does the required key management, so no sweat on that side. Less technical, but slightly more detailed about how Auto Key works. http://www.finalcrypt.org/auto_key.php
– Ron de Jong – 2019-07-16T08:47:00.837
1Nobody has said how to encrypt a directory. – chovy – 2014-10-18T08:50:40.620
1@chovy Not that above it says:
For dirs:
gpg-zip -c -o file.gpg dirname – celebdor – 2014-10-20T10:33:24.113
@celebdor missed that one. thanks. edit: that doesn't work for me. I get some weird encrypted output when I decrypt the file. – chovy – 2014-10-24T15:29:26.913
@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 – 2016-06-12T09:13:16.463
Shouldn't that be "Encryption" and "Decryption"? – mk12 – 2012-07-27T18:41:58.590