gpg - difference --encrypt-to and --recipient
What is the difference between --encrypt-to and --recipient and what are the advantages and disadvantages of using one over the other, which one should you use for encrypting your own files and what does the following mean?
--encrypt-to
... The key specified by name is used only
when there are other recipients given by the user or by use of the
option recipient. ...
encryption gnupg
add a comment |
What is the difference between --encrypt-to and --recipient and what are the advantages and disadvantages of using one over the other, which one should you use for encrypting your own files and what does the following mean?
--encrypt-to
... The key specified by name is used only
when there are other recipients given by the user or by use of the
option recipient. ...
encryption gnupg
add a comment |
What is the difference between --encrypt-to and --recipient and what are the advantages and disadvantages of using one over the other, which one should you use for encrypting your own files and what does the following mean?
--encrypt-to
... The key specified by name is used only
when there are other recipients given by the user or by use of the
option recipient. ...
encryption gnupg
What is the difference between --encrypt-to and --recipient and what are the advantages and disadvantages of using one over the other, which one should you use for encrypting your own files and what does the following mean?
--encrypt-to
... The key specified by name is used only
when there are other recipients given by the user or by use of the
option recipient. ...
encryption gnupg
encryption gnupg
edited Dec 30 '18 at 17:34
Ini
asked Dec 30 '18 at 17:27
IniIni
1086
1086
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
What is the difference between --encrypt-to and --recipient?
Summary:
With
an--encrypt-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption as well as your
own public key. The result: both you and your recipients will be able
to decrypt the files or messages.
Please read the GPG Manual which explains the differences:
--recipient name
-r
Encrypt for user id name. If this option or
--hidden-recipientis not
specified, GnuPG asks for the user-id unless--default-recipientis
given.
And
--encrypt-to name
Same as
--recipientbut 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--recipientor by the asked user id. No trust checking is
performed for these user ids and even disabled keys can be used.
Source Using the GNU Privacy Guard: GPG Key related Options
The documentation is not very detailed/examples may be useful
Here is some more explanation and an example:
"Encrypt-to-Self"
When you encrypt a file or message with the
--encryptcommand, 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-tooption.
You can include the
--encrypt-tooption 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-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption 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-tooption 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>
Source GnuPG Commands - Examples
The documentation is not very detailed. As far as I know you can also your own user-id with--recipientas 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 thenamethat is specified at--encrypt-towill be used. That's why I have no idea what this--encrypt-todocumentation actually tries to convey.
– Ini
Dec 30 '18 at 17:41
Examples may be useful :). I may also be a bug, becausegpgdoes not do what's documented there.
– Ini
Dec 30 '18 at 17:54
1
@Ini Answer updated.
– DavidPostill♦
Dec 30 '18 at 18:36
I 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: 1) So essentially specifiyng two--recipients with one being your own public key is essentially the same as one--encrypt-towith your own public key and--recipientwith Bob's key? 2) Does this mean it doesen't matter which one (--encrypt-toor--recipient) you use to encrypt your own file, but it makes sense to have anencrypt-tostatement with your own pub key ingpg.conf— and therefore it makes sense to use--encrypt-to?
– Ini
Dec 30 '18 at 19:39
3) Does this mean that one sentence of the--encrypt-todocumentation is wrong, because you can use the--encrypt-tooption, without having to specify a--recipientor type one on prompt and the file will be encrypted with the name specified atencrypt-tooption (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"?
– Ini
Dec 30 '18 at 19:39
|
show 6 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1389024%2fgpg-difference-encrypt-to-and-recipient%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
What is the difference between --encrypt-to and --recipient?
Summary:
With
an--encrypt-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption as well as your
own public key. The result: both you and your recipients will be able
to decrypt the files or messages.
Please read the GPG Manual which explains the differences:
--recipient name
-r
Encrypt for user id name. If this option or
--hidden-recipientis not
specified, GnuPG asks for the user-id unless--default-recipientis
given.
And
--encrypt-to name
Same as
--recipientbut 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--recipientor by the asked user id. No trust checking is
performed for these user ids and even disabled keys can be used.
Source Using the GNU Privacy Guard: GPG Key related Options
The documentation is not very detailed/examples may be useful
Here is some more explanation and an example:
"Encrypt-to-Self"
When you encrypt a file or message with the
--encryptcommand, 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-tooption.
You can include the
--encrypt-tooption 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-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption 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-tooption 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>
Source GnuPG Commands - Examples
The documentation is not very detailed. As far as I know you can also your own user-id with--recipientas 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 thenamethat is specified at--encrypt-towill be used. That's why I have no idea what this--encrypt-todocumentation actually tries to convey.
– Ini
Dec 30 '18 at 17:41
Examples may be useful :). I may also be a bug, becausegpgdoes not do what's documented there.
– Ini
Dec 30 '18 at 17:54
1
@Ini Answer updated.
– DavidPostill♦
Dec 30 '18 at 18:36
I 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: 1) So essentially specifiyng two--recipients with one being your own public key is essentially the same as one--encrypt-towith your own public key and--recipientwith Bob's key? 2) Does this mean it doesen't matter which one (--encrypt-toor--recipient) you use to encrypt your own file, but it makes sense to have anencrypt-tostatement with your own pub key ingpg.conf— and therefore it makes sense to use--encrypt-to?
– Ini
Dec 30 '18 at 19:39
3) Does this mean that one sentence of the--encrypt-todocumentation is wrong, because you can use the--encrypt-tooption, without having to specify a--recipientor type one on prompt and the file will be encrypted with the name specified atencrypt-tooption (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"?
– Ini
Dec 30 '18 at 19:39
|
show 6 more comments
What is the difference between --encrypt-to and --recipient?
Summary:
With
an--encrypt-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption as well as your
own public key. The result: both you and your recipients will be able
to decrypt the files or messages.
Please read the GPG Manual which explains the differences:
--recipient name
-r
Encrypt for user id name. If this option or
--hidden-recipientis not
specified, GnuPG asks for the user-id unless--default-recipientis
given.
And
--encrypt-to name
Same as
--recipientbut 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--recipientor by the asked user id. No trust checking is
performed for these user ids and even disabled keys can be used.
Source Using the GNU Privacy Guard: GPG Key related Options
The documentation is not very detailed/examples may be useful
Here is some more explanation and an example:
"Encrypt-to-Self"
When you encrypt a file or message with the
--encryptcommand, 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-tooption.
You can include the
--encrypt-tooption 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-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption 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-tooption 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>
Source GnuPG Commands - Examples
The documentation is not very detailed. As far as I know you can also your own user-id with--recipientas 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 thenamethat is specified at--encrypt-towill be used. That's why I have no idea what this--encrypt-todocumentation actually tries to convey.
– Ini
Dec 30 '18 at 17:41
Examples may be useful :). I may also be a bug, becausegpgdoes not do what's documented there.
– Ini
Dec 30 '18 at 17:54
1
@Ini Answer updated.
– DavidPostill♦
Dec 30 '18 at 18:36
I 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: 1) So essentially specifiyng two--recipients with one being your own public key is essentially the same as one--encrypt-towith your own public key and--recipientwith Bob's key? 2) Does this mean it doesen't matter which one (--encrypt-toor--recipient) you use to encrypt your own file, but it makes sense to have anencrypt-tostatement with your own pub key ingpg.conf— and therefore it makes sense to use--encrypt-to?
– Ini
Dec 30 '18 at 19:39
3) Does this mean that one sentence of the--encrypt-todocumentation is wrong, because you can use the--encrypt-tooption, without having to specify a--recipientor type one on prompt and the file will be encrypted with the name specified atencrypt-tooption (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"?
– Ini
Dec 30 '18 at 19:39
|
show 6 more comments
What is the difference between --encrypt-to and --recipient?
Summary:
With
an--encrypt-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption as well as your
own public key. The result: both you and your recipients will be able
to decrypt the files or messages.
Please read the GPG Manual which explains the differences:
--recipient name
-r
Encrypt for user id name. If this option or
--hidden-recipientis not
specified, GnuPG asks for the user-id unless--default-recipientis
given.
And
--encrypt-to name
Same as
--recipientbut 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--recipientor by the asked user id. No trust checking is
performed for these user ids and even disabled keys can be used.
Source Using the GNU Privacy Guard: GPG Key related Options
The documentation is not very detailed/examples may be useful
Here is some more explanation and an example:
"Encrypt-to-Self"
When you encrypt a file or message with the
--encryptcommand, 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-tooption.
You can include the
--encrypt-tooption 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-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption 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-tooption 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>
Source GnuPG Commands - Examples
What is the difference between --encrypt-to and --recipient?
Summary:
With
an--encrypt-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption as well as your
own public key. The result: both you and your recipients will be able
to decrypt the files or messages.
Please read the GPG Manual which explains the differences:
--recipient name
-r
Encrypt for user id name. If this option or
--hidden-recipientis not
specified, GnuPG asks for the user-id unless--default-recipientis
given.
And
--encrypt-to name
Same as
--recipientbut 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--recipientor by the asked user id. No trust checking is
performed for these user ids and even disabled keys can be used.
Source Using the GNU Privacy Guard: GPG Key related Options
The documentation is not very detailed/examples may be useful
Here is some more explanation and an example:
"Encrypt-to-Self"
When you encrypt a file or message with the
--encryptcommand, 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-tooption.
You can include the
--encrypt-tooption 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-tokey designated in the Options file, GPG
automatically encrypts messages and files to the public keys of the
recipients you specify with the--recipientoption 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-tooption 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>
Source GnuPG Commands - Examples
edited Dec 30 '18 at 18:35
answered Dec 30 '18 at 17:37
DavidPostill♦DavidPostill
105k25227260
105k25227260
The documentation is not very detailed. As far as I know you can also your own user-id with--recipientas 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 thenamethat is specified at--encrypt-towill be used. That's why I have no idea what this--encrypt-todocumentation actually tries to convey.
– Ini
Dec 30 '18 at 17:41
Examples may be useful :). I may also be a bug, becausegpgdoes not do what's documented there.
– Ini
Dec 30 '18 at 17:54
1
@Ini Answer updated.
– DavidPostill♦
Dec 30 '18 at 18:36
I 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: 1) So essentially specifiyng two--recipients with one being your own public key is essentially the same as one--encrypt-towith your own public key and--recipientwith Bob's key? 2) Does this mean it doesen't matter which one (--encrypt-toor--recipient) you use to encrypt your own file, but it makes sense to have anencrypt-tostatement with your own pub key ingpg.conf— and therefore it makes sense to use--encrypt-to?
– Ini
Dec 30 '18 at 19:39
3) Does this mean that one sentence of the--encrypt-todocumentation is wrong, because you can use the--encrypt-tooption, without having to specify a--recipientor type one on prompt and the file will be encrypted with the name specified atencrypt-tooption (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"?
– Ini
Dec 30 '18 at 19:39
|
show 6 more comments
The documentation is not very detailed. As far as I know you can also your own user-id with--recipientas 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 thenamethat is specified at--encrypt-towill be used. That's why I have no idea what this--encrypt-todocumentation actually tries to convey.
– Ini
Dec 30 '18 at 17:41
Examples may be useful :). I may also be a bug, becausegpgdoes not do what's documented there.
– Ini
Dec 30 '18 at 17:54
1
@Ini Answer updated.
– DavidPostill♦
Dec 30 '18 at 18:36
I 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: 1) So essentially specifiyng two--recipients with one being your own public key is essentially the same as one--encrypt-towith your own public key and--recipientwith Bob's key? 2) Does this mean it doesen't matter which one (--encrypt-toor--recipient) you use to encrypt your own file, but it makes sense to have anencrypt-tostatement with your own pub key ingpg.conf— and therefore it makes sense to use--encrypt-to?
– Ini
Dec 30 '18 at 19:39
3) Does this mean that one sentence of the--encrypt-todocumentation is wrong, because you can use the--encrypt-tooption, without having to specify a--recipientor type one on prompt and the file will be encrypted with the name specified atencrypt-tooption (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"?
– Ini
Dec 30 '18 at 19:39
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 the name 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
Dec 30 '18 at 17:41
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 the name 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
Dec 30 '18 at 17:41
Examples may be useful :). I may also be a bug, because
gpg does not do what's documented there.– Ini
Dec 30 '18 at 17:54
Examples may be useful :). I may also be a bug, because
gpg does not do what's documented there.– Ini
Dec 30 '18 at 17:54
1
1
@Ini Answer updated.
– DavidPostill♦
Dec 30 '18 at 18:36
@Ini Answer updated.
– DavidPostill♦
Dec 30 '18 at 18:36
I 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: 1) So essentially specifiyng two
--recipients 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? 2) Does this mean it doesen't matter which one (--encrypt-to or --recipient) you use to encrypt your own file, but it makes sense to have an encrypt-to statement with your own pub key in gpg.conf — and therefore it makes sense to use --encrypt-to?– Ini
Dec 30 '18 at 19:39
I 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: 1) So essentially specifiyng two
--recipients 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? 2) Does this mean it doesen't matter which one (--encrypt-to or --recipient) you use to encrypt your own file, but it makes sense to have an encrypt-to statement with your own pub key in gpg.conf — and therefore it makes sense to use --encrypt-to?– Ini
Dec 30 '18 at 19:39
3) Does this mean that one sentence of the
--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 at encrypt-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"?– Ini
Dec 30 '18 at 19:39
3) Does this mean that one sentence of the
--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 at encrypt-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"?– Ini
Dec 30 '18 at 19:39
|
show 6 more comments
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1389024%2fgpg-difference-encrypt-to-and-recipient%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown