Is it at all possible to symmetrically encrypt multiple files via GPG.. To be more specific I need to encrypt a bunch of files that I just created in a batch with names such as a.txt, 1.txt, A.txt, 2.txt, etc.. But the caveat is they all must be encrypted with different passphrases..

gpg only handles files one at a time when doing symmetric encryption. You would have to do a loop of some kind.

Thanks I came up with this and it works, but the output is "file.txt.pgp" do you know how I can get rid of the .txt part?

Yes, you'd have to calculate the final name and then add the --output option to gpg. As for figuring out the name without .txt before doing the encryption, see Manipulating Strings if you are using bash.

One pragmatic possibility would be to encrypt each of the files, one at a time (each with their individual passphrases), then put them all into a "zip" archive.

Of course, being encrypted, they won't compress at all. But, the single "zip" file will still contain the individual members in a single file from which any member can be extracted, and "everyone on Earth will know how."

Ill just make a bunch of files without the .txt extension, but ill remember this for future scenarios, thank you.

No problem. As an alternative, you could instead run rename over them after the loop is done creating them.

My plan with this is to symmetrically encrypt 152 private key files, which are all meaningless. Only one file in that batch of 152 key files will contain a useful private key that opens my Keepassx database key (which is also encrypted with a symmetric cipher).. This is attempt to secure my private key, and Keepassx database key..

Is the above a bad idea ^?

Awesome thanks for the tip broskies!

I suggest that this is needless complexity. Once someone figures out your "security through obscurity" system, they know that they only need to attack one file. Furthermore, in order to access any of the 151(!) files, you must handle a separate key for each.

Instead, I suggest that you secure the collection of files using one or more certificates, each one issued individually to an authorized recipient. This makes the data far more secure than any "password" could ever allow it to be, while simultaneously making it very convenient(!) for the authorized recipient(s) to handle.

If the system is cumbersome, it probably won't be used as you intended. I myself could not imagine being expected to handle 150 separate keys. Let me give you my public key and you can just encrypt the files using it. No further attempts at "security" are actually needed beyond this. The fact that it is encrypted using a lengthy digital key, that only I possess, is enough. Forget "keypassX." Forget passwords.

Cryptography Rule #1: K. I. S. S.

Passphrases and RSA keys can be embedded in dongles such that they cannot be read or extracted from the dongle. Yubikey and Nitrokey are two that I recall off the top of my head. Neither are cheap but if you get a pair, one for use one for backup, then I think it may fulfill the same goal.

Here's a recent blog post about using a Yubikey 4.

Thanks for your input, you're correct this is a "security through obscurity" system but maybe you misunderstood (or I don't understand something), but I don't plan to "handle" the other 151 keys (but just the one key that I use), as I only make one key then copy it 151 times. Also their all symmetrically enciphered with the same length passphrase so they'll all be similar sizes.. It's true once they understand how this system is set out they be more knowledgeable on what to do. But nevertheless it should be a gamble as there's 152 similar looking files, and I don't see how they could tell which one is my real key.. They would have to waste time brute forcing each one (two times as the pwgen pass is an overlay over the default required pass).. In the end though I'll probably just opt for the certificate idea because its seems more convenient. Thanks again!

Most file systems still mount with some variant of atime active. So, maybe on of these?

I cant try that out atm whatever it is (recently used key history?) but maybe a Bleachbit run can clean that out..