PGP Encryption/GPG Support/Keybase

A number of users want PGP/GPG/Keybase support to Mailspring.

There used to be a Keybase plugin for Nylas mail, but it’s difficult (or impossible) to find now.

This is a priority, but we really need someone familiar with this to help us implement it.


So I assume the difficult part is to implement the encryption/decryption and signing/verification.
I’m not an expert but I’d assume once the mail is parsed these operations are applied to the corresponding parts.
For all the crypto operations we should use an external library like OpenPGPjs. So we just need to make sure that the email is parsed correctly, s.t. the right string goes into the right openPGP function.

Here an example for a signed email:

  1. S/MIME
     Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; 
     Content-Type: multipart/alternative; 
     Content-Type: text/plain; charset=UTF-8
     Content-Transfer-Encoding: quoted-printable
     Content-Disposition: inline
     Content-Type: text/html; charset=UTF-8
     Content-Transfer-Encoding: quoted-printable
     Content-Disposition: inline
     Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
     Content-Transfer-Encoding: base64
     Content-Disposition: attachment; filename="smime.p7s"
     Content-Description: S/MIME Cryptographic Signature
  2. PGP (and autocrypt):
    Autocrypt: addr=...@...; prefer-encrypt=mutual;
    Content-Type: multipart/signed; micalg=pgp-sha1;
    This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
    Content-Type: multipart/mixed; boundary="uiIUBLASCNUasibfu7asulbfyasv23bkasus"
    Content-Type: text/plain; charset=utf-8
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable
    Content-Type: application/pgp-signature; name="signature.asc"
    Content-Description: OpenPGP digital signature
    Content-Disposition: attachment; filename="signature.asc"
    -----END PGP SIGNATURE-----

The Content-Type determines the protocol and boundary which separates the different parts. For S/MIME, we have the email content and then the signature as an smime.p7s file attachment. And for PGP it is a signature.asc file.

I think Enigma mail can be of great help here and a few of their routines can be copied, e.g.:

Enigma mail also uses OpenPGP as their default crypto api: package/cryptoAPI.jsm · master · enigmail / enigmail · GitLab

So looking at this, it seems more doable. But I am not an expert and it seems like the ecosystem is a bit fragmented, with different mime-types for the same thing. Aside from the crypto part there also needs to be an interface to store/search/generate keys or add certificates + changes in the composer to sign/encrypt and in the UI.

Hope that is helpful for anyone who wants to work on this…


There also seems to be a keybase plugin, that could be used as a basis: GitHub - NgoHuy/mailspring-keybase: keybase plugin for mailspring

1 Like

Hi. Andi summed things up quite nicely, but I will try to add to it.

There are two wanted features: encryption/decryption and signing/verification for (1) PGP/GPG and (2) S/MIME. While there are many similarities, they are not the same.

S/MIME is CMS/CAdES format built into the email text format, and there are multiple versions. The latest version seems to be 4.0 (see RFC 8551). The first task you want to cross-out is having a library capable of producing and parsing CMS/CAdES in binary format (which is essentially an ASN.1 structure). When you have such a library, the next step is correctly handling email structure. Standards define two different email formats with an S/MIME signature. AFAIR, they are multipart/signed and application/x-pkcs7-signature, and they differ in signature inclusion. The first format attaches the signature next to the message (the email is a multipart) and the latter envelopes the message within the signature so the message is not visible in the raw email dump. So, in the context of verification, message extraction and verification will differ a bit. In the context of signing, both formats are probably good to use - multipart/signed for signed-only email and the other for signed and encrypted email. Next, for producing signed and encrypted emails, a decision needs to be made whether to first encrypt the message and then sign it, or vice versa. I recommend to consult the Security Considerations in RFCs with this (and make sure that the CMS/CAdES library can handle both because in general, you never really know what you’re going to receive from other email clients). If we come back to correctly handling email structure, the next big thing is correctly handling different Content-Type values. For example, you may not always receive one of the two mentioned Content-Types (email transport layer is generally unreliable to support newest technologies), and in the worst case, the signed message could be buried somewhere deeper in the email structure, or there could be multiple such messages, or there could be nested messages. In these cases, extracting the messages and signatures takes a bit of work, but support for them will likely be postponed until a significant number of users request it - a priority is, of course, to support the most prevalent inputs. The same can also be said about many things concerning the CMS/CAdES structure, signing certificates and their verification, but this is a security-sensitive context, so attention should be paid to properly implement the generation/verification routines. The key is having someone who knows the difference between critical and non-critical things. When it comes to producing signatures, the key thing is support for various private key storages. People may use (e.g.) their operating systems’ key stores, their browser’s key store (FireFox) or an external storage device, usually with a USB connector. I think all three options have something in common: you need to be able to extract the signing certificate from them and use their PKCS#11 interface to produce the signature value for you without getting access to the private key. For PKCS#11 capability, I recommend to include another library into the project. Especially support for USB devices will take a bit of work and tinkering. Signature verification also requires a list of trusted root/intermediate certificates. Again, they may come from (e.g.) operating systems’ trust stores, browser’s trust store (FireFox) or an external trust store (one shipped with the application or explicitly provided by the user). Occasionally, people will want to add a root/intermediate certificate into the trust store. AFAIR, there is potentially a conflict during signature verification in that which email address to verify against which. AFAIR, the “From” header may not always contain the address of the person who actually sent the message and attached the signature. Also, the certified email address may be specified in several places within the certificate, or there may be multiple addresses within. Extracting a list of possible sender addresses and a list of possible certified addresses, and doing an intersection may not be a secure way of verification. What many people could appreciate is a nice and round verification summary, especially when the feature is still young and not fully tested, or when verifications fails. If it were me, I would add an option to display two things somewhere beside the signed message’s viewing canvas: the Common Name or Distinguished Name of the certified subject and the issuer. This would serve as a quick visual check for the user. Ok, I think that sums up the key issues to solve when bringing support for S/MIME. I would have loved to work on this if I had the time but unfortunately, I don’t.

Personally, I have no experience with PGP/GPG on a technical level but I presume it is something quite similar. One of the key differences is that, in this case, some users may prefer not to trust public keyrings and build their own trust stores of public keys. The hard part though is making the trust stores secure because they will likely contain the private keys as well. On some operating systems, perhaps the provided facilities could be used (e.g. KeyChain on macOS), but I’m not completely sure.

In any way, both these endeavours will not be easy, and will require commitment, time and effort if the goal is to support the needs of many people and do it properly. Especially testing may be difficult.


Here’s a possible lead on this.

+1 over here…
Looking forward to PGP Support in Mailspring

@zparihar make sure you vote at the top then.

1 Like

Done! Thx for the reminder.

+1 Need Yubikey support too.

1 Like

I would love mail spring to support gpg, but honestly I’ve given up on the idea of the majority of my contacts being able correspond this way and I doubt they will change to differ mail clients.

What I have found useful is emacs’ ability to encrypt/decrypt a region of text. This lets you paste a message into the body of a normal message.

What options are there to allow mail spring to open an external editor or perhaps parse the body or selected region of text to an external program?