You can use GPG to symmetrically encrypt a file with a passphrase (gpg -c
). If the passphrase has enough entropy, you don't need an extra step of generating a secret key. What does “enough entropy” mean? Your encryption needs to withstand offline attacks, where the attacker can make cracking attempts as fast as his hardware allows it. With a small PC farm, the attacker might be able to make a couple hundred billion attempts per second, which is roughly 2^69 per decade. So with an entropy of 2^70 you'll be safe. That means if your passphrase consists of completely random letters (lower or upper case) and digits, it should be 12 characters long.
Now to store that passphrase, you can use GPG with its usual key pairs. Use gpg --gen-key
to generate a key pair, and gpg -e
to encrypt the passphrase used to encrypt the large file for one or more key pairs.
Here's a sketch on how to do the encryption (note that I avoid putting the passphrase on the command line or in the environment, so as to make sure another user can't find it by looking at the ps
output while the command is running):
passphrase=$(pwgen -s 12 -1)
echo "The passphrase for myiso.iso.gpg is: $passphrase" |
gpg -e -r somebody -r somebodyelse >passphrase.gpg
echo "$passphrase" | gpg -c --passphrase-fd 3 3<&0 <myiso.iso >myiso.iso.gpg
and how to decrypt:
passphrase=$(gpg -d <passphrase.gpg)
echo "$passphrase" | gpg -d --passphrase-fd 3 3<&0 <myiso.iso.gpg >myiso.iso
The reason to use a passphrase (a shared secret) rather than directly encrypt is that it allows the file to be shared between several people. Only the small passphrase needs to be reencrypted if you want to add a recipient (removing a recipient only makes sense if you know the recipient hasn't had access to the plaintext and requires reencoding the ciphertext anyway).
Keys' allowed usages can be modified, but the gpg
tool doesn't support it (even in version 2). To change a key's usage, you need to modify gpg
. The basic idea is detailed in a thread on the gnupg-users
mailing list: usage information is carried by the self-signature, so you need to change the usage parser to force the value you're interested in, then create a new self-signature on your key, for example by changing your key's expiry date.
Best Answer
Have you tried the following:
That should fix the issue.