How many keys do you use for signing and encrypting emails?

Question

Situation

I have a university Gmail email address. I'm trying to migrate away from sending emails with the Gmail web client to one I have more control over like Thunderbird. It's also because Gmail eats up a lot of RAM. I set out to learn about and set up each of TLS, OpenPGP, and S/MIME with respect to email signing and encryption. It's been hard, but not necessarily because of the technical learning curve; I have some coursework experience with cryptography.

I'll also mention that my address is actually an "alias", which is common for us since we're not allowed to change our university ID. This detail will be relevant later.

Where I'm at

• TLS: This was the easy one. I've seen recommendations that the outgoing mail setting should be STARTTLS, and the incoming mail setting should be TLS. That seemed to do the trick when I emailed myself and checked what Gmail had to say about it in their web client.

  However, since TLS is a connection protocol, it makes sense to me that they still actively MITM anything sent through their servers. I'm imagining that even with TLS, I use their public key to send an email, they decrypt and analyze it for advertising and whatever else, and then use my recipient's public key to encrypt that along to them? My link seems to show it's even baked into their ToS. So, I'm trying to get the others set up.

• S/MIME: My university has an in-house CA that can issue me a certificate for use with S/MIME. However, their portal only issues this certificate for our original IDs and not under email aliases. Gmail doesn't take this cert in their web client, i.e. Accounts & Import -> Send mail as -> edit info -> Upload a personal certificate, because the emails don't match. Again, this seems like a security concern too, since I would be escrowing my key(s) with Google. This leads me to two questions:

  1. I can't tell how many certificates I need. From Wikipedia, I've read

     The accepted best practice is to use separate private keys (and associated certificates) for signature and for encryption, as this permits escrow of the encryption key without compromise to the non-repudiation property of the signature key.

     This goes uncited, although I can understand and agree with the statement. It's unclear to me though if there are any security risks in not using two S/MIME certificates. I've read answers on IS Stack Exchange that seem to present conflicting evidence. Nevertheless, my CA doesn't issue more than one cert at a time, so I'm unsure whether this is currently an option for me at all. I'm still communicating with technical support about certificate questions.

     Question: Is there any security risk in using a single S/MIME certificate?

  2. I'd like to not have to choose between my primary/alias email address and encryption.

     Question: I haven't tested it in Thunderbird yet, but is there anything actually blocking me from still using a cert with a different email address?

• OpenPGP: I've seen a lot more conflicting evidence of how many keys to use here. For example, Enigmail (apparently the de facto plugin) for Thunderbird seems to default to creating a single GPG key with its setup wizard. The OpenPGP Security settings don't even have separate entry boxes to enter separate signing and encryption keys, but yet the Security settings tab does. Also, to quote the previous source again, it was recommended in 2011 to have separate signing and encryption keys (especially for RSA) for security reasons. But in 2015, a "duplicate" question has an answer suggesting that this isn't the case and it's perfectly fine to use a single GPG key for signing and encryption---regardless of the algorithm, too.

  Question: Is there any security risk in using a single GPG key?

  Question: Which algorithms are best to pick from, circa 2020?

  Question: If you'd be kind enough (especially for others who might read your answer and are still trying to connect the dots), could you offer an example of how to do your recommendations in practice? (gpg and Thunderbird would be ideal, since I and many others with interests in privacy & security use Linux, but I'll take whatever you have experience with) GPG is known for a high learning curve, after all.

Thank you.

Answer 1

Well all of these crypto have a different purpose and nice problem they solve:

• TLS, protect the communication between server and client. (And server to server). If a public CA is used than this can also be used to authenticate where a message came from (server 2 server that is)
• S/MIME, is a encapsulation crypto around a specific message. It only works between known participants that all use s/mime (or atleast have it setup correctly). It’s quite hard to setup s/mime correctly and it will only protect the message itself, not the header info.
• pgp, is a sign and encryption protocol that can be applied to (almost) anything. While it can encrypt the full message it can be used to verify the original message (most headers still must be send in a clear text format). Pgp also has a way to discover keys so participants do not need to know participants (although it does help). Also it’s trust is not based on a centralized authority but on your own thrust. (There is no CA).

As to using a key for both signing and encryption l, that is up to you. Separating them will allow you to revoke and replace them individually as needed. However many use-cases for replacing and revoking have to do with lost keys. Usually you lose them both together. You also often need both keys together when you use the keys.

So you can make a case either way about it.

As for what algorithm. If you need compatibility RSA is the way to go. Otherwise a Elliptical Curve is often faster with the same level of encryption. Which one depends on support you need.

As for S/MIME and the e-mailadres. This is baked into the certificate so you can not use a different email address with a specific certificate. Your message would never be decryptable by the other side even if you would force (or trick) the system to use it.

In conclusion it’s up to you to decide what you want to do. There are certainly options each with there own pitfalls and downsides.