It’s been a long time since I wrote on this blog. I recently attended a talk with Phil Zimmerman recently and it was the opportunity to reuse pgp/gpg and I thought it was a good idea to talk about it.

Why

I often had the questions why I would need to use strong encryption, especially since it used to be very illegal in my own country (there was a limit on 40 bits in France back when I started using cryptography). Usually, people tend to say that if you use cryptography, you must be hiding stuff and probably doing some very illegal and dangerous. I beg to differ on this topic: I keep my personal data in my home, which is usually locked. If a judge comes and ask to open the drawer, I’ll gladly do it if the due process is rightly followed. In the same way, I consider that my communication is private and while I’ll surrender my private key to the right officials and the right request, I prefer not having anyone being able to excess its authorization and illegally eavesdrop on me, which seem to have been a pretty common game for most governments. In a pettier way, some company sysadmin might be overusing their privilege and while you may trust them to watch you personal folder, it might be interesting to make sure they actually can’t do it.

Theory

Private/public keys

Quick reminder on theory:

• you want your communication to be secure (i.e. not easy to listen to silently)
• you want your communication to be authenticated (i.e. I need to be sure whom I’m talking to) and non compromised (i.e. if someone attempts at modifying the message, I want to know).

This can be enforced through cryptography the following way:

• signing with a private key will allow anyone having the corresponding public key to check the integrity of the message. Trusting that the set of key actually belong to the person you’re thinking about is a different problem.
• ciphering with a public key will allow only the target private key to read the message. Practically, message is ciphered with a random session key and that key is ciphered using the public key (for performance reason).

One fun side effect is that you need to encrypt the session key with the public key of each of the message recipient, including the ones in BCC, hence displaying them on the clear. You’ve been warned.

Trust

While using asymmetric cryptography ensures that only a set of key is involved, knowing whether this set of key actually belong to an individual is a different problem. To solve this, the concept of “web of trust” exist. The principle is that at any time, you can check the real life identification of someone and cryptographically sign their key, hence providing the community that you checked that a given person is who they claim to be. Then, if you trust someone who trust someone else, you’re likely to actually trust that some one else to be who they pretend to be.

Practically

Generating a key

I’ll explain how to do most command using gpg command line, mostly as a reminder for me. There are several bazillions tools to help you automate and work around these process.
Modern standards seem to use a 4096 RSA key (this won’t prevent you from having your communication read when quantum computer will be there, so if you care…). Elliptic curves can be as safe for shorter keys but are not widely supported yet. The passphrase will be protecting your private key, it seems to be a very good idea to have something really strong here. I’m not talking about reusing a 8 letters web password kind of strong, but writing a full sentence that only you will remember kind of strong (like a pass-phrase, not a pass-word).

gpg --full-gen-key

This will generate a key, including a key id and a fingerpint:

bruce@morannon:~$ gpg --fingerprint C3F53DD4
pub 4096R/C3F53DD4 2016-06-10
 Key fingerprint = 77EE B582 C4AA 7724 AD2D 53AC AC42 DF1E C3F5 3DD4
uid Florent Revelut (Bruce) <florent@revelut.ch>
sub 4096R/92F7C250 2016-06-10

The id (C3F53DD4 in my case) will be used to identify your key. The fingerprint will be used when cross checking identities (i.e. if you check and identity, you need to be sure that you check the fingerprint)

Signing someone else key

Say I want to sign my old key FBE03BF7 with my new and shiny one C3F53DD4.

Make sure you have the key, if not get it from a keyserver (pgp.mit.edu is a common alternative)

gpg --keyserver pgp.mit.edu --recv-keys FBE03BF7

Sign the key (level 3 is the highest level of trust, meaning you checked really closely an official id)

gpg --sign-key --default-cert-level 3 --no-ask-cert-level -u C3F53DD4 -a FBE03BF7

Export the key to a file

gpg -a --export FBE03BF7 > FBE03BF7.txt

and prepare a to send it to your stakeholder (this will generate a FBE03BF7.txt.asc that you can safely cut and paste in an e-mail)

gpg -u C3F53DD4 --armor --recipient FBE03BF7 -e -s FBE03BF7.txt

delete the key form your local keyring, you’ll get it from a keyserver later when you need it

gpg --delete-key FBE03BF7
rm FBE03BF7.txt

Importing a signature

You’ll probably receive ane-mail with a file attachment named something.asc. You’ll have to decrypt it:

gpg -d *.asc > clear.txt

Then probably extract the file attachment, this will generate new files

munpack clear.txt

Then import the signature (check whatever file was generated in previous step). It will merge the new signature with the existing ones.,

gpg --import florent@revelut.ch.asc

Then publish it:

gpg --keyserver pgp.mit.edu --send-keys C3F53DD4

And done : your public keyis now available, including the trusted signature from your stakeholders.

Traps/tips

If you encrypt an e-mail/a file you’re sending to someone else, you’d better encrypt it for you as well or you won’t be able to read it later (remember, you don’t have the private key of your recipient). If you have the file “in clear” on your file system, you will definitely want to delete it in a safer way than rm. Depending on your OS, file system and caching policies, this might get tricky to make sure your content is actually properly wiped out (or close to impossible).

Enigmail is a very easy and user friendly way to cipher your e-mails. If you’re using a web-app to access your e-mail, you might  want to switch to using a real mail client and imap to access your emails as webapp usually don’t support cryptography. It might eventually be coming for gmail though (blog post from google).

Cryptography and BCC don’t work well together: the IDs of all recipients are in the clear… In the same way, ciphering and mailing list don’t work unless you have a way to expand the mailing list on client side and know all recipients (think about exchange server). There is no issue with signing cryptographically when sending to a mailing list and it’s considered a good practice.

You can (and should) use your private key when tagging a git repository. As you put your reputation on line, you might want to review branch merge with extra care.

Most people won’t check the signature of the public key, which is really bad. Anyone can publish a public key on a key server, if it’s not signed, it does not bring anything.

Some extra paranoid people don’t want ot have their public key hosted on a key server. There are some use cases where it makes sense, use your best judgement on convenience vs security.