File: gnupg.info,  Node: GPG Key related Options,  Next: GPG Input and Output,  Prev: GPG Configuration Options,  Up: GPG Options

4.2.2 Key related options
-------------------------

'--recipient NAME'
'-r'
     Encrypt for user id NAME.  If this option or '--hidden-recipient'
     is not specified, GnuPG asks for the user-id unless
     '--default-recipient' is given.

'--hidden-recipient NAME'
'-R'
     Encrypt for user ID NAME, but hide the key ID of this user's key.
     This option helps to hide the receiver of the message and is a
     limited countermeasure against traffic analysis.  If this option or
     '--recipient' is not specified, GnuPG asks for the user ID unless
     '--default-recipient' is given.

'--recipient-file FILE'
'-f'
     This option is similar to '--recipient' except that it encrypts to
     a key stored in the given file.  FILE must be the name of a file
     containing exactly one key.  'gpg' assumes that the key in this
     file is fully valid.

'--hidden-recipient-file FILE'
'-F'
     This option is similar to '--hidden-recipient' except that it
     encrypts to a key stored in the given file.  FILE must be the name
     of a file containing exactly one key.  'gpg' assumes that the key
     in this file is fully valid.

'--encrypt-to NAME'
     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".  It is suggested to use a fingerprint or at
     least a long keyID for NAME.  These keys are only used when there
     are other recipients given either by use of '--recipient' or by the
     asked user id.  No trust checking is performed for these user ids
     and even disabled keys can be used.

'--hidden-encrypt-to NAME'
     Same as '--hidden-recipient' but this one is intended for use in
     the options file and may be used with your own user-id as a hidden
     "encrypt-to-self".  It is suggested to use a fingerprint or at
     least a long keyID for NAME.  These keys are only used when there
     are other recipients given either by use of '--recipient' or by the
     asked user id.  No trust checking is performed for these user ids
     and even disabled keys can be used.

'--no-encrypt-to'
     Disable the use of all '--encrypt-to' and '--hidden-encrypt-to'
     keys.

'--group {NAME=VALUE}'
     Sets up a named group, which is similar to aliases in email
     programs.  Any time the group name is a recipient ('-r' or
     '--recipient'), it will be expanded to the values specified.
     Multiple groups with the same name are automatically merged into a
     single group.

     The values are 'key IDs' or fingerprints, but any key description
     is accepted.  Note that a value with spaces in it will be treated
     as two different values.  Note also there is only one level of
     expansion -- you cannot make an group that points to another group.
     When used from the command line, it may be necessary to quote the
     argument to this option to prevent the shell from treating it as
     multiple arguments.

'--ungroup NAME'
     Remove a given entry from the '--group' list.

'--no-groups'
     Remove all entries from the '--group' list.

'--local-user NAME'
'-u'
     Use NAME as the key to sign with.  Note that this option overrides
     '--default-key'.

'--sender MBOX'
     This option has two purposes.  MBOX must either be a complete user
     ID containing a proper mail address or just a plain mail address.
     The option can be given multiple times.

     When creating a signature this option tells gpg the signing key's
     user id used to make the signature and embeds that user ID into the
     created signature (using OpenPGP's "Signer's User ID" subpacket).
     If the option is given multiple times a suitable user ID is picked.
     However, if the signing key was specified directly by using a mail
     address (i.e.  not by using a fingerprint or key ID) this option is
     used and the mail address is embedded in the created signature.

     When verifying a signature MBOX is used to restrict the information
     printed by the TOFU code to matching user IDs.  If the option is
     used and the signature contains a "Signer's User ID" subpacket that
     information is is also used to restrict the printed information.
     Note that GnuPG considers only the mail address part of a User ID.

     If this option or the said subpacket is available the TRUST lines
     as printed by option 'status-fd' correspond to the corresponding
     User ID; if no User ID is known the TRUST lines are computed
     directly on the key and do not give any information about the User
     ID. In the latter case it his highly recommended to scripts and
     other frontends to evaluate the VALIDSIG line, retrieve the key and
     print all User IDs along with their validity (trust) information.

'--try-secret-key NAME'
     For hidden recipients GPG needs to know the keys to use for trial
     decryption.  The key set with '--default-key' is always tried
     first, but this is often not sufficient.  This option allows
     setting more keys to be used for trial decryption.  Although any
     valid user-id specification may be used for NAME it makes sense to
     use at least the long keyid to avoid ambiguities.  Note that
     gpg-agent might pop up a pinentry for a lot keys to do the trial
     decryption.  If you want to stop all further trial decryption you
     may use close-window button instead of the cancel button.

'--try-all-secrets'
     Don't look at the key ID as stored in the message but try all
     secret keys in turn to find the right decryption key.  This option
     forces the behaviour as used by anonymous recipients (created by
     using '--throw-keyids' or '--hidden-recipient') and might come
     handy in case where an encrypted message contains a bogus key ID.

'--skip-hidden-recipients'
'--no-skip-hidden-recipients'
     During decryption skip all anonymous recipients.  This option helps
     in the case that people use the hidden recipients feature to hide
     their own encrypt-to key from others.  If one has many secret keys
     this may lead to a major annoyance because all keys are tried in
     turn to decrypt something which was not really intended for it.
     The drawback of this option is that it is currently not possible to
     decrypt a message which includes real anonymous recipients.