"Encrypt-to-Self"
When you encrypt a file or message with the --encrypt
command, you
are encrypting with someone else's public key. Strangely enough, even
though you encrypted the file or message yourself, you won't be able
to decrypt that encrypted file and access the plaintext. The only
person who can decrypt the file is the owner of the secret key that is
the partner of the public key used to encrypt the file. That's the
nature of asymmetric, public key encryption: you encrypt with the
public key and decrypt with the secret key (private key). If you don't
keep a copy of the plaintext original file yourself (and you probably
shouldn't for security reasons), then you face being locked out of the
very files and messages that you have encrypted and sent to other
people. Happily, there is a solution: the --encrypt-to
option.
You can include the --encrypt-to
option in your Options file and
specify your own public key. This option is often called the
"encrypt-to-self" option, because it tells GPG to encrypt the message
with your own public key as well as your recipient's public key. With
an --encrypt-to
key designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the --recipient
option as well as your
own public key. The result: both you and your recipients will be able
to decrypt the files or messages.
To use the --encrypt-to
option in your Options file, drop the
leading dashes ( -- ) and specify your own key's Key ID. (You can get
your own Key ID with the --list-keys command.) For example, Bob (whose
Key ID is 0x3FAD9F1E) could include the following line in his Options
file:
encrypt-to 0x3FAD9F1E
(Note that even though Bob's key includes an encryption subkey with a
separate Key ID, he simply uses the Key ID for his master key.)
Now Bob can encrypt a file to his friend Phil, just as he normally
would...
D:\TEMP>gpg --recipient Phil --encrypt my-file.txt
D:\TEMP>
...and still turn around and decrypt the file himself.
D:\TEMP>gpg --decrypt my-file.gpg
You need a passphrase to unlock the secret key for
user: "Bob Bone <bobbone@cowtownu.edu>"
2048-bit ELG-E key, ID AB53B492, created 2001-11-13 (main key ID 3FAD9F1E)
Enter passphrase: My_31337_Passphrase
gpg: encrypted with 2048-bit ELG-E key, ID 42F0A0A0, created 1997-04-07
"Philip R. Zimmermann <prz@pgp.com>"
gpg: encrypted with 2048-bit ELG-E key, ID AB53B492, created 2001-11-13
"Bob Bone <bobbone@cowtownu.edu>"
This is my file.
I have many such files.
But this is the file I'm working with now.
D:\TEMP>
The documentation is not very detailed. As far as I know you can also your own user-id with
--recipient
as an "encrypt-to-self". I'm not posting a question about a quotation to get the same quotation as an answer ;|. I mean what does it mean "to be used only when there are other recipients given..." That statement is not even a correct, because you can specify no recipient at all and thename
that is specified at--encrypt-to
will be used. That's why I have no idea what this--encrypt-to
documentation actually tries to convey. – Ini – 2018-12-30T17:41:20.717Examples may be useful :). I may also be a bug, because
gpg
does not do what's documented there. – Ini – 2018-12-30T17:54:55.0731@Ini Answer updated. – DavidPostill – 2018-12-30T18:36:20.257
1I have some more questions just to be unambigous and make this complete — maybe you can incorporate the answers to those questions into your answer too:
--recipient
s with one being your own public key is essentially the same as one--encrypt-to
with your own public key and--recipient
with Bob's key?--encrypt-to
or--recipient
) you use to encrypt your own file, but it makes sense to have anencrypt-to
statement with your own pub key ingpg.conf
— and therefore it makes sense to use--encrypt-to
?start="3">
--encrypt-to
documentation is wrong, because you can use the--encrypt-to
option, without having to specify a--recipient
or type one on prompt and the file will be encrypted with the name specified atencrypt-to
option (as mentioned in question two of the above comment)? That contraticts with the documentation text "is used only when there are other recipients given by the user or by use of the option recipient"?I've no idea what you are asking in the last comment. It seems clear to me. Read
--encrypt-to name
again. "Same as --recipient but this one is intended for use in the options file and may be used with your own user-id as an "encrypt-to-self". These keys are only used when there are other recipients given either by use of --recipient or by the asked user id. " – DavidPostill – 2018-12-30T19:45:06.427Yeah but according to that documentation when you only specify
--encrypt-to
, but no--recipient
, then the value of--encrypt-to
should also not be used and that means we would have no valid command and that there should be an error, which is not the case in thegpg
implementation. – Ini – 2018-12-30T19:49:18.013{shrug} If the docs are wrong it's not my fault. I've answered as best as I can ... – DavidPostill – 2018-12-30T19:52:00.500
1@Ini So the short-short answer is encrypt-to is the "Same as --recipient but this one is intended for use in the options file", and the confusion is from an (unusual?) case of documentation bloat? – Xen2050 – 2018-12-31T01:44:46.723
Yes, it seems so – Ini – 2018-12-31T10:13:50.917