I've found gpg -c < unencrypted_file > encrypted_file this command from https://askubuntu.com/questions/27770/is-there-a-tool-to-encrypt-a-file-or-directory this page, but in gpg manual it says gpg --output test.gpg --symmetric test.out something like this. I couldn't find anything about first one is an alias on the manual page so i want to see is there a difference and tested like this:

create 500Mb file first

dd if=/dev/urandom of=./tmpfile bs=1000000 count=500

time gpg -c <tmpfile> file1 (19 secs)

time gpg --output file2 --symmetric tmpfile (21 secs)

time gpg --output file3 --symmetric tmpfile (21 secs)

time gpg -c <tmpfile> file4 (20 secs)

second command seems a bit slower to me, is this because of coincidence or are these commands different?

edit: gpg version is 1.4.20


Yes, these commands are effectively the same:

gpg -c < file > file.gpg
gpg --output file.gpg --symmetric file

First, -c is just a shorthand for --symmetric:

 -c, --symmetric             encryption only with symmetric cipher

Also note that the characters < and > are used in Bash for I/O redirection, they are not part of GPG's option syntax.

What's going on here is that GPG can take input from either stdin or a file specified as an argument. Instead of giving the filename as an argument, < FILE just feeds it via stdin. When GPG notices that input is given via stdin, it will print the output to stdout by default instead of creating a file (unless you use --output). So you can just redirect stdout with > FILE to write the encrypted data to a target file.

| improve this answer | |
  • ahh, < for input and > for output, i thought it's wrapping only input like <inputfilename>, thanks for reply. Can we use these i/o feeds for zip files, binary files etc or just for text files? – rugowimola Nov 17 '17 at 0:54
  • @rugowimola You can use < and > for arbitrary data streams, including zip files. – Arminius Nov 17 '17 at 1:00
  • Thanks, one more thing but last :) i didn't find anything about spaces on this link about i/o redirection. < input > output causes any difference from <input> output ? – rugowimola Nov 17 '17 at 1:03
  • @rugowimola No, that should be fine. – Arminius Nov 17 '17 at 1:04

second command seems a bit slower to me, is this because of coincidence or are these commands different?

They might be equivalent in high-level functionality, but they're clearly not identical; the two commands don't match exactly, so they're not identical.

It's no coincidence that they're equivalent in functionality, as the decision for gpg to use stdin and stdout couldn't possibly have been unintentional.

However, what is coincidental is that one is slower than the other. There are factors at play here such as file buffering which may vary in specification and performance between implementations of the C standard library let alone the POSIX terminal. Simply put, one may be slower on your computer, yet faster or equal speed on another hardware configuration, using a different compiler or standard library.

From a security standpoint (which is what this site is about), you should use whichever you're most comfortable using. I imagine the user interface designers added both interfaces to provide an alternative for shell configurations which don't support pipes, and that alone doesn't seem to pose a significant security risk.

| improve this answer | |

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.