Most email isn’t secure

When you send a typical email message, it’s readable by more than just the sender and recipients. Without a secure TLS/SSL¹ connection between peers, anyone between a sender and recipient can read a message by monitoring network traffic (often even others users of the same network; or worse, public wifi hotspot). Even with TLS/SSL protecting the initial transmission, subsequent mail servers may not continue the use of encryption, and a message is usually still readable “at rest” when stored on each mail server between the communicating parties.

To send a truly secure email message, the contents of the message itself must be encrypted in a way that only the sender and recipient understand. This leaves only the “metadata” of the message exposed (the sender, recipient, date, etc). Without the metadata, mail servers wouldn’t know how to route the message.

The 8.1 release includes support for encrypted email communication using the OpenPGP² standard.

Symmetric encryption

At its core, encryption requires a “shared secret” that both the sender and receiver know in order to exchange secure messages. This is called symmetric encryption because both parties have the same information. The secret would need to be shared in a secure way. In the past, this involved an in-person rendezvous or trusted couriers.

Asymmetric encryption

However, it’s not always possible or practical to physically exchange a secret with everyone you want to securely communicate with (especially not on the Internet). This led to the advent of asymmetric encryption, where parties can securely communicate without establishing a shared secret beforehand. They have different information which can be combined cryptographically to unlock a shared secret.

In an asymmetric system, each participant has a pair of encryption keys³ – one is made public and the other is kept private. These keys are typically stored as files.

The public key can be used by anyone to encrypt messages for a particular recipient, or to verify authorship of their messages.
The private key is used to decrypt messages that were encrypted by the paired public key, or to sign messages to prove authorship.

Both of these systems have tradeoffs:

Symmetric encryption (the shared secret) is relatively fast and can encrypt a large amount of data.
Asymmetric encryption (the public/private keys) is computationally complex and best used with a small amount of data.

OpenPGP

OpenPGP combines the strengths of both approaches. Each time a new message is encrypted, a random shared secret is generated by the sender and used to symmetrically encrypt the message. That shared secret is then asymmetrically encrypted with the recipient’s public key and included with the encrypted message. If there are multiple recipients, each of their public keys is used to encrypt a copy of the same secret, while the encrypted message remains identical for each person. The shared secret for each message is disposable – it’s not reused for any subsequent communication.

Here’s what that process looks like:

source: wikipedia

What does a public key look like?

Here’s our own public key:

Public key servers

The important thing to keep in mind with public keys is that you trust their source. Encryption doesn’t do you any good if you’re tricked into sending secret messages to the wrong person.

OpenPGP opts for a decentralized “web of trust” where peers sign each others keys to certify their authenticity. This is in contrast to the issuance of SSL certificates, which relies on a central authority.

We highly recommend using a service like Keybase⁴, which not only verifies the email address of a public key, but also allows the key owner to prove their identity by verifying ownership of domain names, profiles on various services (e.g. Twitter, GitHub), Bitcoin wallets, etc.

You can import public keys from Keybase right into Cerb.

Sending encrypted messages in Cerb

In Cerb 8.1, you can manage public keys from Search » Public Keys.

When adding a new record by clicking on the (+) above the worklist, you can import a public key by pasting it:

You can then see all the information about a public key from its card:

When you compose email or send a reply, there’s a new Encrypt message using recipient public keys option. Cerb will automatically check your keyring for matching public keys based on the recipient email addresses (they should match UIDs on the keys). A single public key can specify multiple email addresses as UIDs.

To send an encrypted message, you must have a public key on file for every recipient. If you don’t, you’ll see an error message like this:

Here’s what an encrypted email message looks like when it’s traveling over the network:


Message-ID: <af1d48312aa8449f709a6d5a35086d81@localhost>
Date: Wed, 16 Aug 2017 19:06:49 -0700
Subject: This message is encrypted
From: support@cerb.ai
To: support@webgroupmedia.com
MIME-Version: 1.0
Content-Type: multipart/encrypted; protocol="application/pgp-encrypted";
 boundary="_=_swift_v4_1502935609_82fe295e000d2484f7388d11c98b8d53_=_"
X-Mailer: Cerb 8.1.0 (Build 2017080801)
X-Peer: 127.0.0.1

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)

--_=_swift_v4_1502935609_82fe295e000d2484f7388d11c98b8d53_=_
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

--_=_swift_v4_1502935609_82fe295e000d2484f7388d11c98b8d53_=_
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

-----BEGIN PGP MESSAGE-----

hQEMA4urH5p9m7zMAQgAs6O2vfSfbtouMXigJDlqvWPJLMD4TpYwX/rW2+58Z7NS
xBgNyf7/MIp1OMLs33jn8w93uFDgJqAgrj018ixx9kgaru5WrHYnVPrv38cCWaMw
DfShRU2bf/ALGkGRMyWK2JV/xP1iesnON80eaAJhwOXTJE/uvUNkZ5F+1iJ6n5Pf
hSOAsLGlcmOCxbibK+lpVmK+o89Ovzr7HJMvOmZxhGEZDQfPe1lrYkt7lBX3WNMo
GRfWyASgPNmdBYfDPzk0A6W05tq98f1rwuURJFVyBSz2zPcoJlzbsOLQKkw0YGs1
nBqaZg7zYLptxH9BJ+gpNL08IEf6mtF5W5hGAnNfX4UBDANqLe/9Yjd1jgEIANV6
plExVdmb+ycTg41MrsPytWGByEuX39qq+cfrpgv2gh1A/HMhVP7kygqS3PH8thL6
UbXahqsHiNl/ZbJEuhKgj5k3Q0YLMbeGTfN2PpOd4cNhVXSZH0FBh2u4sIsYxSU9
u2gDdR5+3F4z3FnME/LuqMz6/iT2tgzrNlK70aTaS/qUsN6jCe40IwM0wAFbj1gm
PeiRG7zaZ8F9C7UuXk9H5Izt6rruDFJIKw1yoxZvFnX/krCjfjd09ThIozNmbixh
0Hk4lkcseToTxl1hu5who2xOQ8Y7wWNGy9nwX8s/ncRPRR17hh1xTASI9lv46fev
8DxB8aQSxRtSF50HbhLS6QFtPrgOOmb+9DZwCizK/h9aNwhj03dOwUxWArLgihWE
7R3v+2H+KyFlXw58pcPHPWfCV9tqoGdcTB39KWS3CYS7aCNO9mJaN+7rS97ysNPr
KYL2ZLUpuP3kDqclf2VkGZOls8kU/53HmQQKs+breT3kwArLPrSpR67vsXcBXsKU
lYQ53ovAIiJ3R5A6q6r5G2fbdV8JYwFlrafG+ac0pmBkv6AkiQUWrYayNcGZJJ2z
GLHuLH4ekiXr2hnXD5ckJVEOfRy9ACNu3xkFbXENI59G3K0W9Vep7xvjsD3awD6p
7N8xzzNZ5h7owUOQDXiQQNEXWzbJq1V3alm9N0jtE2oScPlRtHzqpbHqb4h9CJ1d
1RCg1NfKaFAKyMmBLPuK5Pp8kik7gjDKDZ1JfAs1vrO24stD9z7jyIJ/cPixt7jH
+KoQPJ4gV6wHX6Z2n5LR6zZAiVjKQuYGL/Uw39E2kzYKChULth6DgokgaeKoaoyJ
mqiL54AKDHR73Z2Ojgiq4hj//vdGhOZfT235Hjzlc8Mqkg7ZslVOzTr8M46I+0om
xSvicPfGuR1T2+OrmPS2sf1iIUZeO4KvTEB9uix0QkNLz+K29eXg7xyEWRCxSb0J
un+n+nC9jK5U0n3yP7Bn7txQsyHMsoMc/JXogour6ItdE40JGefyFSGUmFgT8U9k
wEqvHVxAxTy4Q49ol0KEKlWuA5w/VbwLZ5J55OUzOVK9BRn+4YxGAsDoFZttRrOx
VPiVauG/HP95r7/M8WhTPPcQOqHDHIlbYW/tYgu4oyDrhQA9IBVnO/m4JrjhFSHs
WkT2HhyoF2naP83u1R4vFGpvqGaDQcJ/wKmvO9UJWDHBeOWnmvtMsRERcwB8QSa3
YQN6kiRugEPwuTN6d5vCZfin/JbnasbmVfVGDdv/oyYXoXHRzNfkTb7USQ6Iz4jQ
AeMahpG9NomjH1tPHVYlJEXIzThxxC0NrPASiot+Cgx1UzvUqB/Kc37+97fnnaHx
jyOi8AknGL+XJlOh2t0lJjAJ6KbbFQIbUJ6moQ==
=L2VM
-----END PGP MESSAGE-----


--_=_swift_v4_1502935609_82fe295e000d2484f7388d11c98b8d53_=_--

In conversation threads in Cerb, we add a badge for any messages that were encrypted when sent or received:

Receiving encrypted messages in Cerb

To automatically decrypt a received encrypted message in Cerb, you need to have the corresponding private key in your keyring. If you receive an encrypted message that can’t be decrypted, Cerb will leave the encrypted content as an attachment on the message that you can decrypt offline. This is the most secure option, but the content of the message won’t be readable or searchable within Cerb.

If you want automatic decryption of messages, you need to consider the security implications of leaving your private key on the server. At the minimum, we recommend that you create a new decryption subkey without storing your master private key on the server. We’re also exploring options for browser-based decryption.

References

Wikipedia: Transport Layer Security (TLS) - https://en.wikipedia.org/wiki/Transport_Layer_Security ↩
Wikipedia: OpenPGP - https://en.wikipedia.org/wiki/Pretty_Good_Privacy ↩
Wikipedia: Public-key Cryptography - https://en.wikipedia.org/wiki/Public-key_cryptography ↩
Keybase - https://keybase.io/ ↩

Send encrypted email using OpenPGP