Strong encryption is no longer a privilege of geeks and paranoids but is becoming mainstream. However, true end-to-end encryption is not out-of-the-box and generally requires you to activate a number of switches as described in this post about Instant Messaging. OpenPGP encryption is no exception and you must follow a few good practices to make it more secure. This blogpost will provide you with a concise list of OpenPGP encryption best practices.
Public keys and Public Key Server (PKS)
- Do not blindly trust keys from public servers
Anyone can upload keys to public key servers and there is no reason that you should trust the given relationships (the association between the email ID and the public key). You should therefore verify with the owner the full key fingerprint of their key.
- Always verify public keys with your intended recipients
It is recommended that you should do this verification in real life or over the phone.
If this is not possible, then look on places like social media, personal website, blog,… which belong to the individual you want to have a key fingerprint of – as some people simply publish their public key fingerprint.
- Check key fingerprints before importing
Verify the fingerprint first, before importing it.
- Never rely on the Key ID
Always check a given OpenPGP public key via its fingerprint.
Even 64 bits long OpenPGP Key IDs (for e.g., 0x44434547b7286901 –) probability of collision is potentially a very serious problem.
- Update public keys in your keystore
If you don’t update the public keys in your key store, then you do not get timely expirations or revocations – both of which are very important to be aware of. Mailfence allows you to achieve this by simply clicking on “update from public server” on any imported public key that you have in your keystore.
If possible, perform deniable key exchange!
You can deniably exchange keys by having an easily available and identifiable public key. Tell all correspondents to use your public key to contact you and include their public key in the encrypted body of the message. This will protect you from all mainstream key-exchange attacks. Just ensure that your public is verifiable through multiple channels, for example: social media, public mailing lists, key servers, etc. The more channels that host your PGP key fingerprint, the harder it is for Eve to attack them all.https://blog.mailfence.com/openpgp-encryption-best-practices
OpenPGP Key generation and configuration
Now that you know how to receive regular key updates from a well-maintained key server, you should make sure that your OpenPGP key is optimally configured. Many of these changes may require you to generate a new key.
- Have a strong private key
Mailfence by default generates 4096bit RSA key. But if you’re planning to generate your private key using an external tool – then make sure it is either 2048 or 4096 bit-length.
- Use an expiration date
Users generally don’t want their keys to expire, but there are good reasons to let them. Why? The point is to setup something that disables your key in case you lose access to it or if it has been compromised (and you have no revocation certificate). You can always extend your expiration date, even after it has expired! This “expiration” is actually more of a safety valve that will automatically trigger at some point. If you have access to the secret key material, you can prevent the expiration.
Set a calendar event to remind you about your expiration date
It’s best to setup a calendar event in your Mailfence calendar that will remind you at the right time to extend your OpenPGP key expiration date.
Again, you can always extend your expiration date even after it has expired! You do not need to make a brand new key, you just need to extend your expiration to a later time.
- Generate a revocation certificate
In case you forget your passphrase or if your private key is compromised or lost, the only hope you have is to wait for the key to expire (this is not a good solution). A better approach is to activate your revocation certificate by publishing it on Public key servers. Doing this will notify others that you revoked the key.
However, a revoked key can still be used to verify old digital signatures, or decrypt data. On condition that you still have access to the private key.
- Other OpenPGP key checks
If you have generated your private key using Mailfence, do not worry about these points, they do not apply to you:
– Make sure your key is OpenPGPv4
– Your OpenPGP keys should be DSA-2 or RSA (RSA preferred), ideally 4096 bits or more.
– Your OpenPGP keys should have a reasonable expiration date (no more than 2 years in the future)
Additional suggestions for OpenPGP encryption best practices
- Do you have an encrypted backup of your secret key material?
Please double check. Ideally, you should backup your key (encrypted with your passphrase by default) both in the cloud and on your local machine. Also, make a back-up of your revocation certificate on your local machine.
Note: Keep in mind that your revocation certificate is ready-to-use. If a crook gets access to it, then he/she can use it to revoke your key.
- Do not include a “Comment” in your User ID.
OpenPGP User ID is usually to mention your name or alias and not for commenting.
- Pay attention towards Public key servers
Most OpenPGP based applications come with a single, specific key server. This is not ideal because if the key server fails, or even worse, if it appears to work but is not functioning properly, you may not receive critical key updates. Not only is this a single point of failure, it is also a prime source of leaks of relationship information between OpenPGP users, and thus a target for attacks.
Therefore, it is good not to base yourself on only one public key server for publishing or importing keys. Mailfence uses sks keyservers pool – a pool of servers having 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.
Finally, all your interactions with the keyserver should be encrypted (over TLS/SSL – hkps), which will obscure your social relationship map from anyone who may be snooping on your traffic.
Replying to an encrypted email, sent items and drafts
Delete the decrypted content in a reply to an encrypted email, and only quote the relevant parts if necessary. Configure your application to not save drafts by default and discard the encrypted messages from sent items or don’t keep them in plain-text. Mailfence by default perform all such operations for you.
- Protect your meta-data
Minimizing the contextual information leakage from the communication is also a good practice by simply hiding the meta-data (to, from, ip address, etc). Where possible, and relevant, take control over that infomation and unlink it from data linked to you. For example, you can control the From field by creating a new email account. The IP address of the sending email client can be changed by using a VPN, Tor, or a public Internet connection. The usual caveats about Tor apply: do not rely exclusively on Tor, if you need to protect your IP address then use an IP address that is not attributable to you.
Subject line must never ever refer to the content of the email (or at best, left empty), even obliquely. For example, “Subject: It was nice meeting you at Eiffel Tower!” is a total email security failure.
Want to go a bit further, read following good documents for OpenPGP encryption best practices
- https://riseup.net/en/security/message-security/openpgp/best-practices (hardcore tips – a bit outdated)
- https://alexcabal.com/creating-the-perfect-gpg-keypair/ (hardcore tips)
- https://wiki.debian.org/Keysigning (all software from official Debian and Ubuntu is signed with OpenPGP)
Note: If you presently do not keep your email account secure, then our OpenPGP encryption best practices will not help you. We would advice you to check on how to keep your private email account secure.
Mailfence – a secure and private email service. Follow us on twitter/reddit and keep yourself posted at all times.
