security - Is there a way to revoke a GPG encryption key?
2014-07
Matt
OK, so as I understand it, the key revocation mechanism is used to revoke a signing key in your web of trust: so you say to other GPG users that your previously-used identity has been compromised, and you wish to establish a new identity that is still you (still maintains the same level of trust); ignore the old key, that's "not me" anymore. Therefore, it is not possible to encrypt a message to the "old" me, nor is it possible to consider the "old" me trusted anymore for new messages.
However, it is possible for the "old" secret key to decrypt old messages. For example: read just under "Generating a revocation certificate".
Is there a method with GPG in which something similar can be done to revoke an encryption key? Say that you have a laptop which gets stolen with both ones' keys and some encrypted files (financial data, say) and you wish to remove the laptop's ability to decrypt those files. Clearly, if the laptop never connects to a keyserver, it would never get a revocation, but is there a method by which one can create a revocation of the encryption key such that, should that laptop contact a keyserver and get the revocation message, the files are no longer decryptable?
(and yes, my secret key is password protected by a long, hard-to-brute-force password, but still, I was curious if there were a more-sure way to kill the decryptability of a key).
mtak
No it is not possible to stop a GPG key from decrypting content that was encrypted with it simply because it contains the key needed to decrypt the data. You cannot tell a file to not be decrypted.
The GPG web of trust enables you to tell others to not trust your key anymore. They won't encrypt new content with your key anymore (that's the idea). However, old content can still be decrypted.
If you want to keep your data secure, decrypt it with your old key and reencrypt it with a new key.
Jens Erat
Revocations in OpenPGP
A revocation is a message signed by your own key that is published to the key servers (or distributed otherwise) announcing that some other OpenPGP message is not valid any more, possibly enriched by a reason and date.
Revocations can be issued for eg. keys or certifications (signatures) of other keys. The revocation will prevent others (that have received the revocation) to further use/trust the key.
Revocations and Decryption
Consider the results of such a message in case somebody has both access to your secret key (possible including the used passphrase) and the message to be decrypted. If a revocation preventing the attacker from decrypting the message would exist, he just would not update the key or ignore the message (remember that OpenPGP is a public protocol, you can always create your own implementation or modify an existing one).
Preventing the decryption is not possible, if the attacker has the secret key for decrypting it.
Thomas
I'm trying to generate keys to lock my drive (using DM-Crypt with LUKS) by pulling data from /dev/random and then encrypting that using GPG.
In the guide I'm using, it suggests using the following command:
dd if=/dev/random count=1 | gpg --symmetric -a >./[drive]_key.gpg
If you do it without a pipe, and feed it a file, it will pop up an (n?)curses prompt for you to type in a password. However when I pipe in the data, it repeats the following message four times and sits there frozen:
pinentry-curses: no LC_CTYPE known assuming UTF-8
It also says can't connect to '/root/.gnupg/S.gpg-agent': File or directory doesn't exist, however I am assuming that this doesn't have anything to do with it, since it shows up even when the input is from a file.
So I guess my question boils down to this: is there a way to force gpg to accept the passphrase from the command line, or in some other way get this to work, or will I have to write the data from /dev/random to a temporary file, and then encrypt that file? (Which as far as I know should be alright due to the fact that I'm doing this on the LiveCD and haven't yet created the swap, so there should be no way for it to be written to disk.)
serbaut
Make sure you own the tty:
# ls -l $(tty)
crw--w----. 1 foo tty 136, 0 Mar 1 16:53 /dev/pts/0
# chown root $(tty)
Set GPG_TTY:
# export GPG_TTY=$(tty)
gpg/pinentry should work after these steps.
Thomas
Well...in the end, I decided to just write out to a file, and then encrypt that file, assuming that since there was no swap, and the filesystem was in ram, that it would die with the next shutdown.
However, for the reference of anyone who finds this question (and to cement the idea in my head), I will write down a procedure I found that would work long after I found out when creating the initramfs.
What you need to do is go back to a version of gpg before they started using the external pinentry program for password entry. As far as I know, that happened with version 2. Assuming that you have a currently working Linux install, you will want to get a statically compiled version of gpg<2.0.
This is extremely easy to do with Gentoo, only requiring the following command:
USE="static" emerge -a1 "<gnupg-2"
Just make sure to use ldd to confirm that they are in fact static before you copy them to your thumb drive so that you can use them during the install.
On other distributions, I suggest you look @ your package manager, and if that doesn't work, then I would try downloading the sources, and compiling from them.