Gpg Generate Key Long Time

Related

• Gpg Generate Key
• Gpg Generate Key

How To Install and Configure Postfix as a Send-Only SMTP Server on Ubuntu 18.04 Tutorial

The Red Hat Customer Portal delivers the knowledge, expertise, and guidance available through your Red Hat subscription. Creating GPG Keys Using the Command Line. Feb 28, 2016  gpg-keygen. A readme and a script to generate PGP keys using GnuPG, using the current best practices. Its goal is to provide a concise and up-to-date description of best practices regarding the usage of GnuPG.

How To Set Up and Configure an OpenVPN Server on CentOS 8 Tutorial

Introduction

GPG, or GNU Privacy Guard, is a public key cryptography implementation. This allows for the secure transmission of information between parties and can be used to verify that the origin of a message is genuine.

In this guide, we will discuss how GPG works and how to implement it. We will be using an Ubuntu 16.04 server for this demonstration, but will include instructions for other distributions as well.

How Public Key Encryption Works

A problem that many users face is how to communicate securely and validate the identity of the party they are talking to. Many schemes that attempt to answer this question require, at least at some point, the transfer of a password or other identifying credentials, over an insecure medium.

Ensure That Only the Intended Party Can Read

To get around this issue, GPG relies on a security concept known as public key encryption. The idea is that you can split the encrypting and decrypting stages of the transmission into two separate pieces. That way, you can freely distribute the encrypting portion, as long as you secure the decrypting portion.

This would allow for a one-way message transfer that can be created and encrypted by anyone, but only be decrypted by the designated user (the one with the private decrypting key). If both of the parties create public/private key pairs and give each other their public encrypting keys, they can both encrypt messages to each other.

So in this scenario, each party has their own private key and the other user’s public key.

Validate the Identity of the Sender

Another benefit of this system is that the sender of a message can “sign” the message with their private key. The public key that the receiver has can be used to verify that the signature is actually being sent by the indicated user.

Set Up GPG Keys

GPG is installed by default in most distributions.

If for any reason GPG is not installed, on Ubuntu and Debian, you can update the local repo index and install it by typing:

On CentOS, you can install GPG by typing:

To begin using GPG to encrypt your communications, you need to create a key pair. You can do this by issuing the following command:

This will take you through a few questions that will configure your keys:

• Please select what kind of key you want: (1) RSA and RSA (default)
• What keysize do you want? 4096
• Key is valid for? 1y (expires after 1 year. If you are just testing, you may want to create a short-lived key the first time by using a number like “3” instead.)
• Is this correct? y
• Real name: your real name here
• Email address: your_email@address.com
• Comment: Optional comment that will be visible in your signature
• Change (N)ame, ©omment, (E)mail or (O)kay/(Q)uit? O
• Enter passphrase: Enter a secure passphrase here (upper & lower case, digits, symbols)

At this point, gpg will generate the keys using entropy. Entropy describes the amount of unpredictability and nondeterminism that exists in a system. GPG needs this entropy to generate a secure set of keys.

This process may take a long time depending on how active your system is and the keysize you selected. To generate additional entropy more easily, you can use a tool called haveged. Open up a new terminal and SSH into the server again to set up haveged on your server.

Create a Revocation Certificate

You need to have a way of invalidating your key pair in case there is a security breach or in case you lose your secret key. There is an easy way of doing this with the GPG software.

This should be done as soon as you make the key pair, not when you need it. This revocation key must be generated ahead of time and kept in a secure, separate location in case your computer is compromised or inoperable. To generate a revocation key, type:

You will be asked to confirm the revocation key creation and then prompted for the reason that it is being revoked. This information will be visible to other users if the revocation is used in the future. You can choose any of the available options, but since this is being done ahead of time, you won’t have the specifics. Often, it is a good idea to create a revocation certificate for each of the likely scenarios for maximum flexibility.

Afterwards, you will then be asked to supply a comment and finally, to confirm the selections. Before creating the revocation certificate, you will need to enter your GPG key’s passphrase to confirm your identity. The revocation certificate will be written to the file specified by the --output flag (revocation.crt in our example):

You should immediately restrict the permissions on the generated certificate file in order to prevent unauthorized access:

The revocation certificate must be kept secure so that other users cannot revoke your key. As the message states, you should consider backing the certificate up to other machines and printing it out, as long as you can secure it properly.

How To Import Other Users’ Public Keys

GPG would be pretty useless if you could not accept other public keys from people you wished to communicate with.

You can import someone’s public key in a variety of ways. If you’ve obtained a public key from someone in a text file, GPG can import it with the following command:

There is also the possibility that the person you are wishing to communicate with has uploaded their key to a public key server. These key servers are used to house people’s public keys from all over the world.

A popular key server that syncs its information with a variety of other servers is the MIT public key server. You can search for people by their name or email address by going here in your web browser:

You can also search the key server from within GPG by typing the following:

You can use this method of searching by name or email address. You can import keys that you find by following the prompts.

How To Verify and Sign Keys

While you can freely distribute your generated public key file and people can use this to contact you in a secure way, it is important to be able to trust that the key belongs to who you think it does during the initial public key transmission.

Verify the Other Person’s Identity

Gpg Generate Key

How do you know that the person giving you the public key is who they say they are? In some cases, this may be simple. You may be sitting right next to the person with your laptops both open and exchanging keys. This should be a pretty secure way of identifying that you are receiving the correct, legitimate key.

But there are many other circumstances where such personal contact is not possible. You may not know the other party personally, or you may be separated by physical distance. If you never want to communicate over insecure channels, verification of the public key could be problematic.

Luckily, instead of verifying the entire public keys of both parties, you can simply compare the “fingerprint” derived from these keys. This will give you a reasonable assurance that you both are using the same public key information.

You can get the fingerprint of a public key by typing:

This will produce a much more manageable string of numbers to compare. You can compare this string with the person themselves, or with someone else who has access to that person.

Sign Their Key

Signing a key tells your software that you trust the key that you have been provided with and that you have verified that it is associated with the person in question.

To sign a key that you’ve imported, simply type:

When you sign the key, it means you verify that you trust the person is who they claim to be. This can help other people decide whether to trust that person too. If someone trusts you, and they see that you’ve signed this person’s key, they may be more likely to trust their identity too.

You should allow the person whose key you are signing to take advantage of your trusted relationship by sending them back the signed key. You can do this by typing:

You’ll have to type in your passphrase again. Afterwards, their public key, signed by you, will be displayed. Send them this, so that they can benefit from gaining your “stamp of approval” when interacting with others.

When they receive this new, signed key, they can import it, adding the signing information you’ve generated into their GPG database. They can do this by typing:

They can now demonstrate to other people that you trust that their identity is correct.

How To Make Your Public Key Highly Available

Because of the way that public key encryption is designed, there is not anything malicious that can happen if unknown people have your public key.

With this in mind, it may be beneficial to make your public key publicly available. People can then find your information to send you messages securely from your very first interaction.

You can send anyone your public key by requesting it from the GPG system:

You can then send this file to the other party over an appropriate medium.

If you want to publish your key to a key server, you can do it manually through the forms available on most of the server sites.

Another option is to do this through the GPG interface. Look up your key ID by typing:

The highlighted portion in the output below is the key ID (look for the pub along the left-hand column if you’re uncertain about which one to use). It is a short way to reference the key to the internal software.

To upload your key to a certain key server, you can then use this syntax:

The key will be uploaded to the specified server. Afterwards, it will likely be distributed to other key servers around the world.

Encrypt and Decrypt Messages with GPG

You can easily encrypt and decrypt messages after you have shared your keys with the other party.

Encrypt Messages

You can encrypt messages using the “–encrypt” flag for GPG. The basic syntax would be:

This encrypts the message using the recipient’s public key, signs it with your own private key to guarantee that it is coming from you, and outputs the message in a text format instead of raw bytes. The filename will be the same as the input filename, but with an .asc extension.

You should include a second “-r” recipient with your own email address if you want to be able to read the encrypted message. This is because the message will be encrypted with each person’s public key, and will only be able to be decrypted with the associated private key.

So if it was only encrypted with the other party’s public key, you would not be able to view the message again, unless you somehow obtained their private key. Adding yourself as a second recipient encrypts the message two separate times, one for each recipient.

Decrypt Messages

When you receive a message, simply call GPG on the message file:

The software will prompt you as necessary.

If instead of a file, you have the message as a raw text stream, you can copy and paste it after typing gpg without any arguments. You can press “CTRL-D” to signify the end of the message and GPG will decrypt it for you.

Key Maintenance

There are a number of procedures that you may need to use on a regular basis to manage your key database.

To list your available GPG keys that you have from other people, you can issue this command:

Your key information can become outdated if you are relying on information pulled from public key servers. You do not want to be relying on revoked keys, because that would mean you are trusting potentially compromised keys.

You can update the key information by issuing:

This will fetch new information from the key servers.

You can pull information from a specific key server by using:

You may receive error messages if any of your keys cannot be found on the key server.

Conclusion

Using GPG correctly can help you secure your communications with different people. This is extremely helpful, especially when dealing with sensitive information, but also when dealing with regular, everyday messaging.

Because of the way that certain encrypted communications can be flagged by monitoring programs, it is recommended to use encryption for everything, not just “secret” data. That will make it more difficult for people to know when you are sending important data or just sending a friendly hello.

A readme and a script to generate PGP keys using GnuPG, using the current best practices.

Its goal is to provide a concise and up-to-date description of best practices regarding the usage of GnuPG. A basic understanding of public key cryptography, and GnuPG in particular is assumed.

If something is not clear or you're new to PGP, then make sure to start with the Glossary below.

Some quick insights

• Public key cryptography happens between two encryption keys, which is not necessarily only two humans, unless enough care has been taken when exchanging public keys and to keep the secret keys indeed secret.
• In a digital networked world it's not possible to delete any published information, it must be assumed to be just there forever. This also applies to PGP keys.
• Properly authenticated revocation requests can be published, though. If such requests are digitally signed (authenticated), then they will be honored by programs handling e.g. PGP keys (key servers, client programs), and the revoked data will be ignored/hidden from the user accordingly.
• Having a separately stored revocation certificate in your backup comes very handy if your key gets compromised or lost. By publishing it you can tell your peers that your key should not be used anymore.
• The most precious part of a PGP key block is its master signing key.
• The master signing key of a PGP key block is rarely needed (mostly when editing/extending the PGP key block itself and when signing other people's keys).
• You can only trust you generated PGP key to the extent you trust the software environment and/or the computer generating it. Opensource is a minimum in security, so use a Linux live cd or something similar from a trusted source to generate and/or use your master signing key, preferably while being offline (see live CD's in the Glossary)!
• Specialized hardware solutions offer much better protection for secret keys. See below.
• If you forget the passphrase for your already published key, and you don't have a revocation certificate either, then your key will be lingering on the keyservers confusing your peers, who will annoy you by sending you messages you cannot read.
• Passphrases: three to five word long sentences that you make up yourself (based on a non-trivial vocabulary, personal experiences, dreams, preferably with s0me typ0s) are easier to remember than a bunch of random characters, and are better passphrases. You can even build a little story around them to have separate but semantically interconnected passphrases (for the keys, for the revocation certificate, etc.). A vivid dream or delightful fantasies can be a good basis for something you won't forget... :)
• ...but at the end of the day it'll always be a tradeoff between security and convenience. Assess your risks and act accordingly.

The PGP algorithm needs an extra parameter, a key, to sign or encrypt data. That parameter is a cryptographic keypair, usually one of the subkeys from a PGP key block. New subkeys can be freely generated and published, so forward secrecy can be achieved by publishing new subkeys, as long as the secret part of the master signing keypair has not been compromised. Therefore the most precious part of a PGP key block is its master signing key, because whenever new information is attached to the key block (e.g. a new subkey is generated), this new data must be signed by the secret part of the master signing keypair, otherwise conforming programs will reject the new unsigned or improperly signed part of the PGP key block. In this scheme publishing valid additions to the key block is only possible by people who know the secret part of the master signing key. This is ideally you, and you only.

So, to conclude: keep the secret part of your master signing key safe!

Generating a key

The aim is to generate a digital identity that can serve to identify you and to facilitate secret communication with you in the future.

Things to consider:

• If a valid signing subkey exists, then the master signing key is rarely used (only to sign internal parts of the key block itself, when explicitly selected, or when signing other people's keys), so the size of the signatures it generates is not a major concern.
• Having a strong master signing key (and taking good care of it) can provide a long time span for your digital identity (possibly 10+ years) and for forward secrecy.
• The security of RSA keys does not scale well beyond 2048 bits, use ECC (Elliptic curve cryptography) instead as recommended. Unfortunately it requires GnuPG 2.1+ (2014 Nov).
• Longer signing keys generate longer signatures.
• Signature length: RSA > DSA = ECDSA (Elliptic Curve DSA) (but there's more to this story).
• Some GnuPG configuration parameters affect newly generated keys (although not in a permanent way); e.g. see setpref to set the preferred hash algorithms for identities here.

Even more thoughts here.

Using GnuPG

GnuPG properly operates with a PGP key block that is missing the secret part of its master signing key, as long as it's not needed for an operation. Therefore it's a good idea not to store the secret part of the master signing key in the regularly used gpg home directory, but rather generate and handle it in a safer environment; e.g. generate and handle it using a live CD without Internet connection, and store it on a pendrive dedicated to this purpose. Then only attach it when needed (e.g. when signing other people's keys or when your own keyblock needs to be modified).

This script generates (with defaults in parens):

• a master signing key (RSA 4096 bit, no expiration date marked)
• a subkey for signing (RSA 4096 bit, 3 years)
• a subkey for encryption (RSA 2048 bit, 3 years)
• export the secret part of the master signing key into the file secret-master-key.gpg
• export the secret parts of the two generated subkeys into the file secret-subkeys.gpg
• export the public parts of all the three generated keys into the file public-keys.gpg
• generate and symmetrically encrypt a revocation certificate into the file revocation-certificate-for-[keyid]-passphrase-protected.gpg
• (planned: support for ssss-split to generate secret sharing to backup the master key and the revocation certificate in a distributed manner)

Once the exported files have been generated, you can import them into the gpg homedir's on your devices (by default ~/.gnupg). Where you should import and what depends on the level of security you want to achieve, but keeping the master key offline is advised as described above.

(the '#' character in the output shows that the secret part of the master signing key is missing)

SmartCards and other hardware keys

SmartCards and USB cryptographic tokens are specialized simple computers that perform cryptographic operations. They are designed to keep the secret keys secret even against physical attacks. They are much more secure than storing a key on a personal computer, but they are not flawless ⁽¹⁾⁽²⁾. Usually they can store three separate keys for signing, encryption, and authentication. The secret keys can be either uploaded or generated on the cards themselves, so that they never get exposed to less secure environments.

• The OpenPGP Card version 2.0 - a SmartCard with extensive documentation and thus stable Linux support. You can also get one by joining the FSFE Fellowship. Supports three 4096 bit keys and on-card key generation⁽¹⁾.
• Crypto Stick - a tiny OpenSource USB computer and firmware with an integrated proprietary smart card chip. Supports OATH TOTP as described here.
• gnuk - a portable OpenSource implementation of the OpenPGP Card specification that can run on e.g. this tiny ARM based OpenSource USB computer.

Some laptops have internal smart card readers, and higher security external readers have their own PIN entry keyboard.

Further information on using smart cards on Linux: Debian wiki, Using an OpenPGP SmartCard, OpenSC – tools and libraries for smart cards, GnuPG wiki.

Glossary

• PGP key - It's usually a shorthand for PGP key block, which will be the case in this document, too. Not to be confused with asymmetric cryptographic keypairs, which are merely parts of PGP key blocks.
• PGP key block - a complex structure of information (normally stored in ~/.gnupg/). Examples of the information it can contain: multiple cryptographic (sub)keys; multiple identities (email addresses, photgraphs, etc); digital signatures on various parts of the key block (potentially made by other people's keys, e.g. to communicate the belief to the rest of the world that the same real world person owns the listed digital identities, and also the secret part of the key).
• subkey - PGP key blocks can have, among other things, multiple asymmetric cryptographic keypairs. One such asymmetric cryptographic keypair is mandatory for normal operation. It's called the master signing key, and it's used to sign various information inside the key block, e.g. identities and/or other cryptographic keys, which are called subkeys.
• asymmetric cryptographic keypair - they are basically pairs of very big interconnected random numbers, one of them should be made public, while the other one should be kept secret. Asymmetric encryption algorithms use the public part to encrypt data and to verify signature blocks, while use the secret part to decrypt data and to generate signature blocks.
• OATH is short for Initiative for Open Authentication. Among other things it defines a Time-based One-time Password (TOTP) authentication standard, supported by more and more websites.
• Live CD is a bootable read-only operating system, like these security focused Linux Live CDs (bootable from USB pendrives also):
  • Liberté Linux.

Alternatives and/or further reading

Credits

Written by Attila Lendvai attila.lendvai@gmail.com (Key fingerprint: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39).

If you've found this useful, then tips are welcome:

Gpg Generate Key

• Bitcoin (BTC): 1Ej8SeMNTkwjSwhKLu7H1XLVRPZ3HUjM4J (0 BTC as of 2014-01-18)
• Ripple (XRP): r33NEgyd7HqvrUeB98rQ4VoBxP438gC74Q (0 XRP as of 2014-01-18)
• Paypal: (0 USD as of 2015-11-10)