Sign a message. This command may be combined with --encrypt (to sign and encrypt a message), --symmetric (to sign and symmetrically encrypt a message), or both --encrypt and --symmetric (to sign and encrypt a message that can be decrypted using a secret key or a passphrase). The signing key is chosen by default or can be set explicitly using the --local-user and --default-key options.
Make a cleartext signature. The content in a cleartext signature is readable without any special software. OpenPGP software is only needed to verify the signature. cleartext signatures may modify end-of-line whitespace for platform independence and are not intended to be reversible. The signing key is chosen by default or can be set explicitly using the --local-user and --default-key options.
Make a detached signature.
Encrypt data. This command may be combined with --sign (to sign and encrypt a message), --symmetric (to encrypt a message that can decrypted using a secret key or a passphrase), or --sign and --symmetric together (for a signed message that can be decrypted using a secret key or a passphrase).
Encrypt with a symmetric cipher using a passphrase. The default symmetric cipher used is AES-128, but may be chosen with the --cipher-algo option. This command may be combined with --sign (for a signed and symmetrically encrypted message), --encrypt (for a message that may be decrypted via a secret key or a passphrase), or --sign and --encrypt together (for a signed message that may be decrypted via a secret key or a passphrase).
Store only (make a simple literal data packet).
Decrypt the file given on the command line (or STDIN if no file is specified) and write it to STDOUT (or the file specified with --output). If the decrypted file is signed, the signature is also verified. This command differs from the default operation, as it never writes to the filename which is included in the file and it rejects files that don’t begin with an encrypted message.
Assume that the first argument is a signed file and verify it without generating any output. With no arguments, the signature packet is read from STDIN. If only one argument is given, the specified file is expected to include a complete signature.
With more than one argument, the first argument should specify a file with a detached signature and the remaining files should contain the signed data. To read the signed data from STDIN, use ‘-’ as the second filename. For security reasons, a detached signature will not read the signed material from STDIN if not explicitly specified.
Note: If the option --batch is not used,
may assume that a single argument is a file with a detached signature,
and it will try to find a matching data file by stripping certain
suffixes. Using this historical feature to verify a detached
signature is strongly discouraged; you should always specify the data file
Note: When verifying a cleartext signature,
only what makes up the cleartext signed data and not any extra data
outside of the cleartext signature or the header lines directly following
the dash marker line. The option
--output may be used to write
out the actual signed data, but there are other pitfalls with this
format as well. It is suggested to avoid cleartext signatures in
favor of detached signatures.
This modifies certain other commands to accept multiple files for processing on the command line or read from STDIN with each filename on a separate line. This allows for many files to be processed at once. --multifile may currently be used along with --verify, --encrypt, and --decrypt. Note that --multifile --verify may not be used with detached signatures.
Identical to --multifile --verify.
Identical to --multifile --encrypt.
Identical to --multifile --decrypt.
List the specified keys. If no keys are specified, then all keys from the configured public keyrings are listed.
Never use the output of this command in scripts or other programs. The output is intended only for humans and its format is likely to change. The --with-colons option emits the output in a stable, machine-parseable format, which is intended for use by scripts and other programs.
List the specified secret keys. If no keys are specified, then all
known secret keys are listed. A
# after the letters
means that the secret key is not usable (for example, if it was
exported using --export-secret-subkeys). See also
Same as --list-keys, but the signatures are listed too. This command has the same effect as using --list-keys with --with-sig-list.
For each signature listed, there are several flags in between the "sig" tag and keyid. These flags give additional information about each signature. From left to right, they are the numbers 1-3 for certificate check level (see --ask-cert-level), "L" for a local or non-exportable signature (see --lsign-key), "R" for a nonRevocable signature (see the --edit-key command "nrsign"), "P" for a signature that contains a policy URL (see --cert-policy-url), "N" for a signature that contains a notation (see --cert-notation), "X" for an eXpired signature (see --ask-cert-expire), and the numbers 1-9 or "T" for 10 and above to indicate trust signature levels (see the --edit-key command "tsign").
Same as --list-signatures, but the signatures are verified. Note that for performance reasons the revocation status of a signing key is not shown. This command has the same effect as using --list-keys with --with-sig-check.
The status of the verification is indicated by a flag directly following the "sig" tag (and thus before the flags described above for --list-signatures). A "!" indicates that the signature has been successfully verified, a "-" denotes a bad signature and a "%" is used if an error occurred while checking the signature (e.g. a non supported algorithm).
Locate the keys given as arguments. This command basically uses the
same algorithm as used when locating keys for encryption or signing and
may thus be used to see what keys
gpg might use. In
particular external methods as defined by --auto-key-locate may
be used to locate a key. Only public keys are listed.
List all keys (or the specified ones) along with their fingerprints. This is the same output as --list-keys but with the additional output of a line with the fingerprint. May also be combined with --list-signatures or --check-signatures. If this command is given twice, the fingerprints of all secondary keys are listed too. This command also forces pretty printing of fingerprints if the keyid format has been set to "none".
List only the sequence of packets. This command is only useful for debugging. When used with option --verbose the actual MPI values are dumped and not only their lengths. Note that the output of this command may change with new releases.
Present a menu to work with a smartcard. The subcommand "help" provides an overview on available commands. For a detailed description, please see the Card HOWTO at https://gnupg.org/documentation/howtos.html#GnuPG-cardHOWTO .
Show the content of the smart card.
Present a menu to allow changing the PIN of a smartcard. This functionality is also available as the subcommand "passwd" with the --edit-card command.
Remove key from the public keyring. In batch mode either --yes is required or the key must be specified by fingerprint. This is a safeguard against accidental deletion of multiple keys.
Remove key from the secret keyring. In batch mode the key must be
specified by fingerprint. The option --yes can be used to
advice gpg-agent not to request a confirmation. This extra
pre-caution is done because
gpg can’t be sure that the
secret key (as controlled by gpg-agent) is only used for the given
OpenPGP public key.
Same as --delete-key, but if a secret key exists, it will be removed first. In batch mode the key must be specified by fingerprint. The option --yes can be used to advice gpg-agent not to request a confirmation.
Either export all keys from all keyrings (default keyrings and those registered via option --keyring), or if at least one name is given, those of the given name. The exported keys are written to STDOUT or to the file given with option --output. Use together with --armor to mail those keys.
Similar to --export but sends the keys to a keyserver.
Fingerprints may be used instead of key IDs. Option --keyserver
must be used to give the name of this keyserver. Don’t send your
complete keyring to a keyserver — select only those keys which are new
or changed by you. If no key IDs are given,
gpg does nothing.
Same as --export, but exports the secret keys instead. The
exported keys are written to STDOUT or to the file given with option
--output. This command is often used along with the option
--armor to allow for easy printing of the key for paper backup;
however the external tool
paperkey does a better job of
creating backups on paper. Note that exporting a secret key can be a
security risk if the exported keys are sent over an insecure channel.
The second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to successfully import such a key. Its intended use is in generating a full key with an additional signing subkey on a dedicated machine. This command then exports the key without the primary key to the main machine.
GnuPG may ask you to enter the passphrase for the key. This is required, because the internal protection method of the secret key is different from the one specified by the OpenPGP protocol.
This command is used to export a key in the OpenSSH public key format. It requires the specification of one key by the usual means and exports the latest valid subkey which has an authentication capability to STDOUT or to the file given with option --output. That output can directly be added to ssh’s authorized_key file.
By specifying the key to export using a key ID or a fingerprint suffixed with an exclamation mark (!), a specific subkey or the primary key can be exported. This does not even require that the key has the authentication capability flag set.
Import/merge keys. This adds the given keys to the keyring. The fast version is currently just a synonym.
There are a few other options which control how this command works. Most notable here is the --import-options merge-only option which does not insert new keys but does only the merging of new signatures, user-IDs and subkeys.
Import the keys with the given key IDs from a keyserver. Option --keyserver must be used to give the name of this keyserver.
Request updates from a keyserver for keys that already exist on the local keyring. This is useful for updating a key with the latest signatures, user IDs, etc. Calling this with no arguments will refresh the entire keyring. Option --keyserver must be used to give the name of the keyserver for all keys that do not have preferred keyservers set (see --keyserver-options honor-keyserver-url).
Search the keyserver for the given names. Multiple names given here will be joined together to create the search string for the keyserver. Option --keyserver must be used to give the name of this keyserver. Keyservers that support different search methods allow using the syntax specified in "How to specify a user ID" below. Note that different keyserver types support different search methods. Currently only LDAP supports them all.
Retrieve keys located at the specified URIs. Note that different installations of GnuPG may support different protocols (HTTP, FTP, LDAP, etc.). When using HTTPS the system provided root certificates are used by this command.
Do trust database maintenance. This command iterates over all keys and builds the Web of Trust. This is an interactive command because it may have to ask for the "ownertrust" values for keys. The user has to give an estimation of how far she trusts the owner of the displayed key to correctly certify (sign) other keys. GnuPG only asks for the ownertrust value if it has not yet been assigned to a key. Using the --edit-key menu, the assigned value can be changed at any time.
Do trust database maintenance without user interaction. From time to time the trust database must be updated so that expired keys or signatures and the resulting changes in the Web of Trust can be tracked. Normally, GnuPG will calculate when this is required and do it automatically unless --no-auto-check-trustdb is set. This command can be used to force a trust database check at any time. The processing is identical to that of --update-trustdb but it skips keys with a not yet defined "ownertrust".
For use with cron jobs, this command can be used together with --batch in which case the trust database check is done only if a check is needed. To force a run even in batch mode add the option --yes.
Send the ownertrust values to STDOUT. This is useful for backup purposes as these values are the only ones which can’t be re-created from a corrupted trustdb. Example:
gpg --export-ownertrust > otrust.txt
Update the trustdb with the ownertrust values stored in
STDIN if not given); existing values will be overwritten. In case of a
severely damaged trustdb and if you have a recent backup of the
ownertrust values (e.g. in the file otrust.txt), you may re-create
the trustdb using these commands:
cd ~/.gnupg rm trustdb.gpg gpg --import-ownertrust < otrust.txt
When updating from version 1.0.6 to 1.0.7 this command should be used to create signature caches in the keyring. It might be handy in other situations too.
Print message digest of algorithm ALGO for all given files or STDIN. With the second form (or a deprecated "*" as algo) digests for all available algorithms are printed.
Emit count random bytes of the given quality level 0, 1 or 2. If count is not given or zero, an endless sequence of random bytes will be emitted. If used with --armor the output will be base64 encoded. PLEASE, don’t use this command unless you know what you are doing; it may remove precious entropy from the system!
Use the source, Luke :-). The output format is still subject to change.
Pack or unpack an arbitrary input into/from an OpenPGP ASCII armor. This is a GnuPG extension to OpenPGP and in general not very useful.
Set the TOFU policy for all the bindings associated with the specified keys. For more information about the meaning of the policies, see trust-model-tofu. The keys may be specified either by their fingerprint (preferred) or their keyid.