0

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.

4
  • Your post includes a range of separate questions, ranging from a) should separate keys be used for signing and encryption b) is it possible to use a certificate which does not match the email c) which algorithms to use d) provide actual examples on how to use it. This makes the question too unfocused and too broad. Please split this up into separate questions and provide only the context needed for the specific sub-question there. – Steffen Ullrich Sep 23 '20 at 6:21
  • I agree that (b) is indeed a separate question that I'm asking out of exasperation with this experience, but your (c) and (d) still belong to the context of (a). (c) especially since I'm linking articles that claim that the algorithm matters for how many keys are used. I can break up my questions if you really think it's too much. – Joshua Detwiler Sep 23 '20 at 6:28
  • "but your (c) and (d) still belong to the context of (a)" - this is how you define the context. Your context currently is basically "how to best use S/MIME and PGP for myself" in which everything is in-context. To be more focused when asking you also have to narrow down the context. "I can break up my questions if you really think it's too much" - if you ask more focused questions you usually get better answers too. So this is in your own interest. – Steffen Ullrich Sep 23 '20 at 6:38
  • @SteffenUllrich, asking a good question is an (often difficult) art, so I understand and mostly agree with your argument. Fortunately, I just got a response that answered enough of my questions (and I'm amazed and grateful at the quality and speed I got...). – Joshua Detwiler Sep 23 '20 at 6:50
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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.