|Last modified: 16-06-2020
Generating a new keypair The command-line option --gen-key is used to create a new primary keypair. alice% gpg --gen-key Generating a revocation certificate After your keypair is created you should immediately generate a revocation certificate for the primary public key using the option --gen-revoke. If you forget your passphrase or if your private key is compromised or lost, this revocation certificate may be published to notify others that the public key should no longer be used. A revoked public key can still be used to verify signatures made by you in the past, but it cannot be used to encrypt future messages to you. It also does not affect your ability to decrypt messages sent to you in the past if you still do have access to the private key. alice% gpg --output revoke.asc --gen-revoke mykey [...] The argument mykey must be a key specifier, either the key ID of your primary keypair or any part of a user ID that identifies your keypair. The generated certificate will be left in the file revoke.asc. If the --output option is omitted, the result will be placed on standard output. Since the certificate is short, you may wish to print a hardcopy of the certificate to store somewhere safe such as your safe deposit box. The certificate should not be stored where others can access it since anybody can publish the revocation certificate and render the corresponding public key useless. Exchanging keys To communicate with others you must exchange public keys. To list the keys on your public keyring use the command-line option --list-keys. alice% gpg --list-keys Exporting a public key To send your public key to a correspondent you must first export it. The command-line option --export is used to do this. It takes an additional argument identifying the public key to export. As with the --gen-revoke option, either the key ID or any part of the user ID may be used to identify the key to export. alice% gpg --output alice.gpg --export firstname.lastname@example.org The key is exported in a binary format, but this can be inconvenient when the key is to be sent though email or published on a web page. GnuPG therefore supports a command-line option --armor that causes output to be generated in an ASCII-armored format similar to uuencoded documents. In general, any output from GnuPG, e.g., keys, encrypted documents, and signatures, can be ASCII-armored by adding the --armor option. alice% gpg --armor --export email@example.com Importing a public key A public key may be added to your public keyring with the --import option. alice% gpg --import blake.gpg Once a key is imported it should be validated. GnuPG uses a powerful and flexible trust model that does not require you to personally validate each key you import. Some keys may need to be personally validated, however. A key is validated by verifying the key's fingerprint and then signing the key to certify it as a valid key. A key's fingerprint can be quickly viewed with the --fingerprint command-line option, but in order to certify the key you must edit it. alice% gpg --edit-key firstname.lastname@example.org pub 1024D/9E98BC16 created: 1999-06-04 expires: never trust: -/q sub 1024g/5C8CBD41 created: 1999-06-04 expires: never (1) Blake (Executioner)
Command> fpr pub 1024D/9E98BC16 1999-06-04 Blake (Executioner) Fingerprint: 268F 448F CCD7 AF34 183E 52D8 9BDE 1A08 9E98 BC16 A key's fingerprint is verified with the key's owner. This may be done in person or over the phone or through any other means as long as you can guarantee that you are communicating with the key's true owner. If the fingerprint you get is the same as the fingerprint the key's owner gets, then you can be sure that you have a correct copy of the key. After checking the fingerprint, you may sign the key to validate it. Since key verification is a weak point in public-key cryptography, you should be extremely careful and always check a key's fingerprint with the owner before signing the key. Command> sign Once signed you can check the key to list the signatures on it and see the signature that you have added. Every user ID on the key will have one or more self-signatures as well as a signature for each user that has validated the key. Command> check alice% gpg --output doc.gpg --encrypt --recipient email@example.com doc blake% gpg --output doc --decrypt doc.gpg Documents may also be encrypted without using public-key cryptography. Instead, you use a symmetric cipher to encrypt the document. The key used to drive the symmetric cipher is derived from a passphrase supplied when the document is encrypted, and for good security, it should not be the same passphrase that you use to protect your private key. Symmetric encryption is useful for securing documents when the passphrase does not need to be communicated to others. A document can be encrypted with a symmetric cipher by using the --symmetric option. alice% gpg --output doc.gpg --symmetric doc Making and verifying signatures A digital signature certifies and timestamps a document. If the document is subsequently modified in any way, a verification of the signature will fail. A digital signature can serve the same purpose as a hand-written signature with the additional benefit of being tamper-resistant. The GnuPG source distribution, for example, is signed so that users can verify that the source code has not been modified since it was packaged. Creating and verifying signatures uses the public/private keypair in an operation different from encryption and decryption. A signature is created using the private key of the signer. The signature is verified using the corresponding public key. For example, Alice would use her own private key to digitally sign her latest submission to the Journal of Inorganic Chemistry. The associate editor handling her submission would use Alice's public key to check the signature to verify that the submission indeed came from Alice and that it had not been modified since Alice sent it. A consequence of using digital signatures is that it is difficult to deny that you made a digital signature since that would imply your private key had been compromised. The command-line option --sign is used to make a digital signature. The document to sign is input, and the signed document is output. alice% gpg --output doc.sig --sign doc You need a passphrase to unlock the private key for user: "Alice (Judge) " 1024-bit DSA key, ID BB7576AC, created 1999-06-04 Enter passphrase: The document is compressed before being signed, and the output is in binary format. Given a signed document, you can either check the signature or check the signature and recover the original document. To check the signature use the --verify option. To verify the signature and extract the document use the --decrypt option. The signed document to verify and recover is input and the recovered document is output. blake% gpg --output doc --decrypt doc.sig Clearsigned documents A common use of digital signatures is to sign usenet postings or email messages. In such situations it is undesirable to compress the document while signing it. The option --clearsign causes the document to be wrapped in an ASCII-armored signature but otherwise does not modify the document. alice% gpg --clearsign doc Detached signatures A signed document has limited usefulness. Other users must recover the original document from the signed version, and even with clearsigned documents, the signed document must be edited to recover the original. Therefore, there is a third method for signing a document that creates a detached signature, which is a separate file. A detached signature is created using the --detach-sig option. alice% gpg --output doc.sig --detach-sig doc You need a passphrase to unlock the secret key for user: "Alice (Judge) " 1024-bit DSA key, ID BB7576AC, created 1999-06-04 Enter passphrase: Both the document and detached signature are needed to verify the signature. The --verify option can be to check the signature. blake% gpg --verify doc.sig doc An algorithm that does work is to use a public key algorithm to encrypt only the signature. In particular, the hash value is encrypted using the signer's private key, and anybody can check the signature using the public key. The signed document can be sent using any other encryption algorithm including none if it is a public document. If the document is modified the signature check will fail, but this is precisely what the signature check is supposed to catch. The Digital Signature Standard (DSA) is a public key signature algorithm that works as just described. DSA is the primary signing algorithm used in GnuPG. Good key management is crucial in order to ensure not just the integrity of your keyrings but the integrity of other users' keyrings as well. The core of key management in GnuPG is the notion of signing keys. Key signing has two main purposes: it permits you to detect tampering on your keyring, and it allows you to certify that a key truly belongs to the person named by a user ID on the key. Key signatures are also used in a scheme known as the web of trust to extend certification to keys not directly signed by you but signed by others you trust. Responsible users who practice good key management can defeat key tampering as a practical attack on secure communication with GnuPG. chloe% gpg --edit-key firstname.lastname@example.org The public key is displayed along with an indication of whether or not the private key is available. Information about each component of the public key is then listed. The first column indicates the type of the key. The keyword pub identifies the public master signing key, and the keyword sub identifies a public subordinate key. The second column indicates the key's bit length, type, and ID. The type is D for a DSA key, g for an encryption-only ElGamal key, and G for an ElGamal key that may be used for both encryption and signing. The creation date and expiration date are given in columns three and four. The user IDs are listed following the keys. More information about the key can be obtained with interactive commands. The command toggle switches between the public and private components of a keypair if indeed both components are available. Command> toggle The information provided is similar to the listing for the public-key component. The keyword sec identifies the private master signing key, and the keyword sbb identifies the private subordinates keys. The user IDs from the public key are also listed for convenience. Using digital signatures is a solution to this problem. When data is signed by a private key, the corresponding public key is bound to the signed data. In other words, only the corresponding public key can be used to verify the signature and ensure that the data has not been modified. A public key can be protected from tampering by using its corresponding private master key to sign the public key components and user IDs, thus binding the components to the public master key. Signing public key components with the corresponding private master signing key is called self-signing, and a public key that has self-signed user IDs bound to it is called a certificate. The GNU Privacy Handbook - Adding and deleting key components
> I'm currently checking out Eudora 5.0.2 for Windows' support for PGP. > One thing that I can't solve, is how to keep a clear-text copy when I > send an encrypted e-mail to someone. Is the only solution to always > add myself to an outgoing e-mail so that I receive an encrypted > version which I can then decrypt? Simple: In Eudora, select "Keep Copies" option (Options-->Sending Mail-->Keep Copies) In PGP, in the Options-->General Tab, check the "Always Encrypt to Default Key" box. Be sure to make your key the default key in "PGPkeys". You should then find a decodable copy in your "sent mail" folder after emailing.