In my last article, I touched on why encryption is important and offered some common sense first steps for your security. Let's expand that discussion by looking at a monumental app called Keybase.
TLDR: Keybase is cryptography for everyone. It's new and fresh and solves PGP's "web of trust" complexity problem. Encryption keys are signed against something you already trust: social media accounts. It is an online identity profile. It's also an app where you can send an encrypted message to anyone in a Slack-like interface.
Before diving in, I will briefly explain PGP.
PGP Encryption
Pretty Good Privacy, or PGP, is an encryption program developed in 1991 by Phil Zimmermann. It can be used for signing, encrypting, and decrypting e-mail, files, and even disks. You give it plain text or binary files and it uses public-key cryptography to output random encrypted ASCII (text) code. Public-key cryptography is widely used and is most commonly seen in website TLS certificates, cryptocurrency transactions such as Bitcoin and SSH authentication.
This mode of encryption is vastly superior to shared-key encryption which is the easiest to understand. With shared-key cryptography, there is one key to both encrypt and decrypt a message. Say I want to share my latest business earnings report with my accountant. I protect the Excel file with a passphrase "Jason swallows banana tacos." I then email the protected file and tell my accountant the password over the phone. This is the shared key.
Note: Notice how I used a phrase rather than a word. It is easy to memorize and more secure than a password such as "b4naNa&67." We've been trained by websites to create difficult to remember passwords that are less secure than a passphrase. "Jason swallows banana tacos" is a lot harder for a computer to crack with brute force. It has a lot more entropy. It is also nonsense (I've never heard of a banana taco), and thus won't be found in any literature for dictionary attacks.
Using a shared key is certainly better than not encrypting at all. But there are drawbacks. What if I can't trust the accountant? If he leaks the password, all our communications can be decrypted by a thief. Even if I trust the accountant, how can I be sure that his computer is not infected by some virus that steals and decrypts the password hash on some GPU farm? Or perhaps some malware is installed on the accountant's computer that captures the password as he types it to open the Excel file I sent him. Further, a shared key does not provide any form of authentication. When I receive an email response from the accountant with the final income statement, how can I be sure that the modified excel file was not tampered with by a man in the middle, a virus, or an email hacker? I can't. I could look at the metadata of the Excel file, but this is easy to spoof. These are all problems that public-key encryption solves.
With public-key encryption, two keys are used: a private key and a public key. The accountant posts his public key in a public place such as a key server. His private key is never shared and is typically stored password-protected on his computer, though it can also be stored on smart card protected by a pin. After the accountant publishes his public key, I can then encrypt the Excel file with his public key. Now only my accountant can decrypt it (I could encrypt the file with my public key as well so I could see what I sent at a later point). When he receives the file, he uses his private key to decrypt the file and start calculating financial things. To handle authentication, I can also sign the Excel file with my digital signature using my private key. When the accountant receives the file, he will be able to verify my digital signature using my public key. He can now be very confident that the financial data actually came from me because I am the only one with access to my private key.
In addition to PGP, public key cryptography is used for SSH authentication for passwordless server administration. This is more secure than using a password as there are no keystrokes to log and access is only permitted for machines that have the private SSH key installed.
Web Of Trust
It is extremely important that the public key I use to send someone a message actually belongs to the recipient. Your public PGP key is essentially your online identity. In the case of the business accountant illustration, we could simply exchange public keys offline and in person. However, what if I want to send a message to someone whom I do not know in person or where physically exchanging keys is practically impossible? In that case, I would need to download the intended recipient's public key from a public key server. But how can I be sure that that public key I found online actually belongs to the intended recipient? After all, it would be pretty easy for an impostor to create a fake public key and post it online. I would then by unwittingly encrypting the message for the impostor who could then read the messages if intercepted (of course this would require an extremely sophisticated and targeted attack). In order to solve this problem, PGP uses a "web of trust". The premise is that while you may not know Sarah personally, your friend Bob can vouch that Sarah's public key actually belongs to Sarah. Bob signs Sarah's key and since I trust Bob, I can be assured that Sarah's key can also be trusted.
This is the web of trust. It is a chain of signatures so that you can be sure that you are using the correct encryption key and not encrypting for an impostor. The problem is, the web of trust is very messy. It takes a lot of effort to manage a keychain with keys for everyone you wish to communicate with. You have to be sure that any new keys you add are linked to your web of trust. You have to check to see if that new public key is signed by one of your other contacts. If it is not signed by anyone you know and trust, then you will need to blindly trust the new key. The "web of trust" idea was formulated decades ago in the early days of the internet. It turns out there is now a better way to authenticate PGP keys and Keybase behind that movement. It is awesome.
Enter Keybase
Rather than relying on the web of trust, Keybase signs keys by verifying social media accounts. Keybase is cryptography for everyone. It's new and fresh and solves and eliminates the complexity of PGP's "web of trust". It can act as a slick online identity profile where your social media accounts are verified and linked together. So if you know me as @brandonkal9 on Twitter you can send me an encrypted Keybase message instantly. Know me as brandonkal on GitHub? You can send me a message. The app is familiar and has a Slack-like interface. It can also be used to encrypt and sync — essentially a Dropbox alternative, but files are protected by your private key. You can use it for team chat or hosting an encrypted git repository. I still prefer to host code on GitHub and GitLab. Keybase helps with that: I can generate a PGP key with Keybase and use it to GPG sign all my git commits to my GitHub and GitLab repositories. The PGP public key is public on my Keybase profile and can be used to independently verify my git commits against the public key. GitHub also has my public key and uses it to display verification badges in the user interface. Without GPG, it is very easy to spoof who made the commit by changing the git email.
Keybase Set Up - Option 1
Simply create a Keybase account. Use a secure password. This password is only for web access and the first device install. Keybase is relatively new so you should be able to get the account name you want. Then download the app. This will install the command line tools. It is best to install Keybase on more than one device. The second device is authenticated by the first. Installing on more than one device ensures your private key is protected in case you ever lose access to one device. Then create a PGP key pair (don't upload the private key as suggested). Finally, sign your social media accounts in the command line:
keybase prove twitter your-username
keybase prove github your-username
keybase prove web https://example.comEach command will output text that you will need to copy and paste and tweet out, post as a Github gist or publish as a keybase.txt file on your website
That is essentially all that is required to install and use Keybase. However, if you want to use it to sign git commits or go the more involved and advanced route (consider your threat model) read on. Don't worry, it is not terribly complicated but I wanted to offer a simple solution for most!
Keybase Set Up - Option 2
This is the route I took. It is a bit more complicated but also secure. The end result consists of:
- A master GPG key stored in a secure environment -- an encrypted live USB locked away.
- A daily use signing key stored on an encryption device.
- Keybase to host the public key and verify your identity with social media.
- SSH private keys also stored on the encryption device
I've decided to break this tutorial into a separate post for readability. I would recommend at least looking through it to decide which route you wish to take. This method required a lot of security research, and I hope the following post helps to get your security up and running in a fast manner. While this post serves as an excellent introduction to Keybase, the next post will serve an excellent reference to the steps required to set up a secure environment and install Keybase to be used in tandem with an externally generated PGP key that exists only on your smart card device.
So without further ado, let's dive in!
Final Note on Recent Events
While reading this article, the term PGP may have brought to mind the recent EFAIL vulnerability. Some even went so far as to claim that PGP was dead in the news cycle. Security researchers uncovered a vulnerability in which an insecure email client could send the decrypted text to an attacker when HTML email content is rendered. This is more of a failure in how email clients render HTML email content instead of the PGP encryption protocol itself.
It is my opinion that PGP on top of the email protocol was never a very good fit for secure communications. The subject line is still unencrypted and other email metadata is just as valuable for a snooping party. You should instead use dedicated apps for secure communications such as Signal or Keybase Chat.
From a recent Keybase email:
Keybase's end-to-end secure chat, our new teams feature, our collaborative encrypted git repositories, and our filesystem all do not use PGP.
To experience EFAIL with Keybase, you must (1) knowingly do this, and then (2) paste a PGP message into an insecure 3rd party app. So don't do that.
PGP as a protocol is still secure. Key sizes have increased as computers have improved but Pretty Good Privacy is still "pretty good."