Documente Academic
Documente Profesional
Documente Cultură
Home (/en)
Email (/en/email)
Security (/en/security)
Lists (/en/lists)
Chat (/en/chat)
VPN (/en/vpn)
About Us (/en/about-us)
https://help.riseup.net/en/security/message-security/openpgp/best-practices
1/12
4/7/2016
https://help.riseup.net/en/security/message-security/openpgp/best-practices
2/12
4/7/2016
suggested changes to the gpg.conf le are gathered in one place near the bottom of this page
(/en/security/message-security/openpgp/best-practices#putting-it-all-together). We strongly encourage
you to not blindly copy the le, but read the document and understand what the settings do.
https://help.riseup.net/en/security/message-security/openpgp/best-practices
3/12
4/7/2016
Therefore, we recommend using the sks keyservers pool (https://sks-keyservers.net/overview-ofpools.php). The machines in this pool have regular health checks to ensure that they are functioning
properly. If a server is not working well, it will be removed automatically from the pool.
You should also ensure that you are communicating with the keyserver pool over an encrypted channel,
using a protocol called hkps. In order to use hkps, you will rst need to install gnupg-curl:
sudo apt-get install gnupg-curl
Then, to use this keyserver pool, you will need to download the sks-keyservers.net CA (https://skskeyservers.net/sks-keyservers.netCA.pem), and save it somewhere on your machine. Please remember the
path that you save the le to! Next, you should verify the certicates nger print (https://skskeyservers.net/verify_tls.php).
Now, you will need to use the following parameters in ~/.gnupg/gpg.conf, and specify the full path
where you saved the .pem le above:
keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem
Now your interactions with the keyserver will be encrypted via hkps, which will obscure your social
relationship map from anyone who may be snooping on your trac. For example, if you do a
gpg --refresh-keys on a keyserver that is hkp only, then someone snooping your trac will see every
single key you have in your key ring as you request any updates to them. That is pretty interesting
information.
Note: hkps://keys.indymedia.org, hkps://keys.mayrst.org and hkps://keys.riseup.net all oer this (although
it is recommended that you use a pool instead).
Ensure that all keys are refreshed through the keyserver you
have selected.
When creating a key, individuals may designate a specic keyserver to use to pull their keys from. It is
recommended that you use the following option to ~/.gnupg/gpg.conf, which will ignore such
designations:
keyserver-options no-honor-keyserver-url
This is useful because (1) it prevents someone from designating an insecure method for pulling their key
and (2) if the server designated uses hkps, the refresh will fail because the ca-cert will not match, so the
keys will never be refreshed. Note also that an attacker could designate a keyserver that they control to
monitor when or from where you refresh their key.
4/12
4/7/2016
The next step is to conrm that you actually got the correct key from the keyserver. The keyserver might
have given you a dierent key than the one you just asked for. If you have gpg with version less than 2.1,
then you must manually conrm the ngerprint after you have downloaded the key (versions 2.1 and later
will refuse to accept incorrect keys from the keyserver).
You can conrm the key ngerprint in one of two ways:
Option 1. Check the ngerprint is now in your keyring:
gpg --fingerprint '<fingerprint>'
If you are condent you have the right ngerprint from the owner of the key, the preferred method is to
locally sign the key. If you want to publicly advertise your connection to the person who owns the key, you
can do a publicly exportable --sign-key instead.
https://help.riseup.net/en/security/message-security/openpgp/best-practices
5/12
4/7/2016
Note the single quote marks above (), which should surround your full ngerprint and are necessary to
make this command work. Double-quotes (") also work.
Key conguration.
Now that you know how to receive regular key updates from a well-maintained keyserver, you should make
sure that your OpenPGP key is optimally congured. Many of these changes may require you to generate a
new key.
https://help.riseup.net/en/security/message-security/openpgp/best-practices
6/12
4/7/2016
Some people still have 1024-bit DSA keys. You really should transition to a stronger bit-length and hashing
algo. In 2011, the US government instution NIST has deprecated
(http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf) DSA-1024, since 2013 it is even
disallowed (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf).
It is recommend to make a 4096bit RSA key, with the sha512 hashing algo, making a transition statement
(https://we.riseup.net/assets/176898/key%20transition) that is signed by both keys, and then letting
people know. Also have a look at this good document (http://ekaia.org/blog/2009/05/10/creating-newgpgkey) that details exactly the steps that you need to create such a key, making sure that you are getting
the right hashing algo (it can be slightly complicated if you are using GnuPG versions less than 1.4.10).
Transitioning can be painful, but it is worth it, and a good opportunity to practice with the tools!
Now select the subkey for which you want to set an expiration date (e.g. the rst one), or none to set the
expiration on your primary key and then issue the expire command:
gpg> key 1
gpg> expire
Then set the date to a reasonable one, and save the key and exit (e.g. 2 years):
Key is valid for? (0) 2y
gpg> save
https://help.riseup.net/en/security/message-security/openpgp/best-practices
7/12
4/7/2016
Then you may send your key to the keyservers to publish this change:
gpg --send-key '<fingerprint>'
This will create a le called revoke.asc. You may wish to print a hardcopy of the certicate to store
somewhere safe (give it to your mom, or put it in your osite backups). If someone gets access to this,
they can revoke your key, which is very inconvenient, but if they also have access to your private key, then
this is exactly what you want to happen.
https://help.riseup.net/en/security/message-security/openpgp/best-practices
8/12
4/7/2016
There is a handy tool that will perform the key checks below for you. You can get it from the source
(http://oss.scru.org/hopenpgp-tools/), or if you are running Debian or Ubuntu, you can install the package
directly by doing:
sudo apt-get install hopenpgp-tools
To run these tests with the tool, you can do the following:
hkt export-pubkeys '<fingerprint>' | hokey lint
The output will display any problems with your key in red text. If everything is green, your key passes each
of the tests below. If it is red, your key fails one of the tests listed below and you should x it or generate a
new key after ensuring that your gpg.conf is set up as recommended.
primary keys should be DSA-2 or RSA (RSA preferred), ideally 4096 bits or more.
To check if you are using DSA-2 or RSA, you can do this:
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets
| grep -A2 '^:public key packet:$' | grep algo
If the reported algorithm is 1, you are using RSA. If it is 17, then it is DSA and you will need to conrm that
the size reported in the next check reports a bit-length key size greater than 1024, otherwise you arent
using DSA-2.
If the reported algorithm is 19, you are using ECDSA, if it is 18 you are using ECC, and the key bit-length
determination check below is not an appropriate criteria for these types of keys as as the key sizes will
drop signicantly.
To check the bit-length of the primary key you can do this:
https://help.riseup.net/en/security/message-security/openpgp/best-practices
9/12
4/7/2016
If you see any digest algo 1 results printed, then you have some self-signatures that are using MD5, as
digest algo 1 is MD5. See the OpenPGP RFC 4880, section 9.4 (https://tools.ietf.org/html/rfc4880#section9.4) for a table that maps hash algorithms to numbers.
To x this, rst, you should set the following in your ~/.gnupg/gpg.conf:
cert-digest-algo SHA512
Second, you should generate a new self-signature on your key (e.g. by changing the keys expiration date
(/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years)).
If you see any digest algo 2 results printed, then you have some self-signatures that are using SHA1, as
digest algo 2 is SHA1. See the OpenPGP RFC 4880, section 9.4
(https://tools.ietf.org/html/rfc4880#section-9.4) for a table that maps hash algorithms to numbers.
To x this, you can generate a new self-signature on your key (e.g. by changing its expiration date
(/en/security/message-security/openpgp/best-practices#use-an-expiration-date-less-than-two-years))
after setting the following in your ~/.gnupg/gpg.conf:
cert-digest-algo SHA512
stated digest algorithm preferences must include at least one member of the
SHA-2 family at a higher priority than both MD5 and SHA1
You can check this by doing:
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets
| grep 'pref-hash-algos'
https://help.riseup.net/en/security/message-security/openpgp/best-practices
10/12
4/7/2016
and then inspect the results. The preference order is based on which number comes rst from left to right.
If you see the number 3, 2, or 1 before you see 11, 10, 9 or 8, then you have specied your
preferences to favor a weakened digest algorithm
To x this, rst set the following in your ~/.gnupg/gpg.conf:
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB B
ZIP2 ZIP Uncompressed
primary keys should have a reasonable expiration date (no more than 2 years in
the future)
You can check what your expiration dates are by doing this:
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets
| grep 'key expires after'
Then visually inspect what the results are to conrm this the date listed will be relative to key creation,
though, which can be dicult to interpret.
Another way to check expiration is just to do:
gpg --list-keys '<fingerprint>'
which should show the creation and expiration dates of the primary key and each associated subkey. If
you dont see anything that says expires in this output, then you have not set an expiration date properly.
To x this, you can do:
$ gpg --edit-key '<fingerprint>'
gpg> expire
...
gpg> save
https://help.riseup.net/en/security/message-security/openpgp/best-practices
11/12
4/7/2016
All the recommended settings discussed on this guide have been combined into one conguration le at
Jacob Appelbaums duraconf (https://github.com/ioerror/duraconf) collection of hardened conguration
les. You may right-click on this link and save the gpg.conf
(https://github.com/ioerror/duraconf/raw/master/congs/gnupg/gpg.conf) in your ~/.gnupg/gpg.conf
(linux and MacOS). For windows users, the gpg.conf le should be saved to AppData\GnuPG\.
You will need to uncomment and/or adjust the following settings to your local preferences: default-key,
keyserver-options ca-cert-file and keyserver-options http-proxy.
Additional suggestions.
Do you have an encrypted backup of your secret key
material?
Double check on it.
You are invited to contribute content and translations for these pages. (https://github.com/riseupnet/riseup_help)
This site is run by
riseup.net, your friendly autonomous tech collective since 1999.
Support Riseup (https://help.riseup.net/donate)
System Status (https://status.riseup.net/)
Mailing Lists (https://lists.riseup.net/)
Email (https://mail.riseup.net/)
About Us (https://help.riseup.net/about-us)
Privacy Policy (https://help.riseup.net/privacy-policy)
https://help.riseup.net/en/security/message-security/openpgp/best-practices
12/12