Bunch of questions on encrypted communication


  1. I want to use my own domain email to communicate professionally and personally.
  2. I hosted my domain and email on a cheap hosting server(like hostgator)
  3. I want to encrypt my email content and attachments when sending and also decrypt secure message received.

My questions are

  1. What is best PGP/GnuPG or S/MIME - based on ease of setting up, compatible email clients availability on major OS.
  2. Based on above preference which email client/s can be used that can be installed in all major OS, plus supports multiple accounts with respective multiple keys.
  3. Best way to store Private Key so that it could be available for mobile devices (may be for configuring say Private Key in the email client)

I have asked around and I got following answers

  1. Better use PGP due to the extensive use cases.
  2. Thunderbird + Enigmail for all Desktops, Canary for iOS, K-9 Mail for Android.

Your valuable insights would be much appreciated…


in order to have a consistent encryption scheme you would have to have EACH person you interact with also adhere to whatever encryption scheme you use.

this might create a lot of unnecessary friction. especially with professional interactions.

is there a explicit need for encryption? are you sharing 0 day exploits or company proprietary intellectual property? or is this for fun?

1 Like

also who are you encrypting it to protect it from? because if you’re aiming to conceal from government entities it’s safe to assume with the various whistle blowing actions of mid level devs that any implementation is moot.

whereas with concerns over private individuals snooping is usually protected by simple best practices.

  1. What is best PGP/GnuPG or S/MIME - based on ease of setting up, compatible email clients availability on major OS.
  1. Best way to store Private Key so that it could be available for mobile devices (may be for configuring say Private Key in the email client)

Keybase and DKIM+SPF+DMARC

  1. Based on above preference which email client/s can be used that can be installed in all major OS, plus supports multiple accounts with respective multiple keys.

Client, anything modern. Thunderbird and K-9 mail are good options so is neomutt.

An important thing to realize is that, with email, it is not possible to establish Forward Secrecy.

This means that if the key is ever compromised down the road (even years later) the email can be decrypted.


The TLS protocol used to exchange mail between properly configured mail servers does support forward secrecy, meaning that your communications should be reasonably secure outside the situation of a compromised Certificate Authority (CA). Checking CAA records helps mitigate this since not any CA will be trusted for the respective domain, but it requires the remote party to enable such records in their DNS and have a known set of CAs.

At this point there are two threat models worth considering:

  • one of the two parties cannot trust the mail provider (encryption at rest can mitigate risk)
  • one of the two parties cannot trust their own organization IT / administrators (encryption can mitigate but only with stringent key control / HSMs. Otherwise they’d just pull the key from your machine)

It comes down to the threat model, as encryption is inherently inconvenient for anything other than ephemeral messages (in which case go to Signal).

Identity & Non-Repudiation

There are two important functions provided by key validation.

  • you know the key is the correct key to encrypt a private message
  • a message you receive you can verify is authentic and could only have been sent by the claimed sender (non-repudiation)

If we want to go down this rabbit hole the first problem is schemes like PGP have a key distribution problem. You can upload keys to a system such as Keybase or the MIT SKS server, but we have to establish the key is actually belonging to the party you desire. Keybase doesn’t do email validation, but offers some form of trust validation through verifying a key is possessed by the same person as, say, a github or twitter account. This is assuming you trust Keybase in your threat model (which, for a typical user without nation state level attacks, you probably won’t have much better). The traditional SKS servers, like pgp.mit.edu, are great in simplicity and automation but provide zero validation so anyone can upload a key claiming it belongs to the email stated.

Practical Usage Problems

Remote Party Implementation

Beyond key distribution problems, we run into the implementation on the receiving as well as the sending end. This requires configuration of reasonable ciphers for the threat model, and all parties agreeing to the encryption choice used. Many professional orgs will not use PGP but instead use S/MIME (which does not have an easy way to handle outside of the org for encryption in practical manners) but is very common and effective for internal org usage. Other orgs will enforce PGP very rigorously for external usage, but ciphers and key support may be limited to traditional RSA and CBC algorithms. These ciphers are fine for the typical threat model.

Key Management

An encrypted PGP key with a strong password can be treated like an encrypted file and shared across devices. PGP does not support ephemeral modes by nature so the keys can be simply shared as-is. Solutions such as Keybase can help with this, but only if you trust Keybase to do primary key management as well as identity validation. The typical PGP users probably don’t do this, but there aren’t good statistics to match.

Long-Term Message Storage Security

This is where services like Protonmail provide some value; in reality they can alter their codebase and view your email anytime they want (they would just need to alter their client-side javascript to send the key off on decryption for whatever user they desire). The fact they are in Switzerland lends some privacy laws, but you’re still placing a not of trust in the service to not be evil.

Services like G Suite, it’s free counterpart Gmail, and similar competitors don’t have the encryption at rest that ProtonMail / Lavabit provide, but in the end if you are encrypting your mail separately it may not be considered a risk in the threat model.

The Mail Server

When running your own mail server you can, of course, encrypt the disk yourself however a mail server has to inherently be able to decrypt to operate. Unless you are shelling out a lot of money on HSMs and boot integrity modes this is quite a significant problem from a practical perspective to prevent complete access by a NOC tech in a datacentre environment. You can make it take more effort, but it’s going to be possible. Even more so with a VPS, since the host organization can choose to dump the memory.

Running mail at home is a bad idea for professional work since it will often trigger common spam filters due to the IP ranges home ISPs own, if your ISP even leaves port 25 available without cutting your service.

Lastly, you of course need to be comfortable configuring the main server and maintaining it from a security and operational perspective.


I’m not going to make this yet another spiel about it since it’s been linked to a lot above, but if you’re running your own mail server you need this.
DKIM generate RSA keys with at least 2048 bits of entropy. This requires a DNS provider with Multi-Line UDP response (for example Namecheap does not support this)

1 Like

I will use only for ethical use cases. One of them is ‘Privacy’, as my domain and email service is hosted on a third party service provider like hostgator. I could have used Protonmail, but its a bit costly for me.

Also, I am planning to write a paper on the ‘Thread Model of an Average Person’.

You mean there is no way one can be safe from state snooping?

What are those best practices?

You’re looking at a lot of hassle for little benefit. It’s very easy to screw up and relies on all parties not making mistakes. The most common failure is the receiving person replies without encryption and includes your original reply because that’s the default behaviour of email clients.

This is already overkill for the average person; doing infosec for a living I just run G Suite Enterprise ($20/mo) for my domain, since it has fanastic security implementations and constantly updated (the most common email problems are on the mail systems themselves, not the transport).
For stuff I can’t trust Google knowing I run a layer of PGP as needed or use a document delivery appliance I run out of my colo.

You can also run an appliance like this for documents in particular for recipients/senders that don’t have PGP / other things setup: https://www.liquidfiles.com/
An appliance like that is very common in modern professional orgs to avoid botched PGP implementations.

This mostly means you’re going to have implementation problems in one way or another. Almost all encryption suites have some form of trade off and the parties involved have to be on their toes to mitigate those.

It’s all about reasonable risk. You could for example run an XOR cipher with a key the same length of your content and no one can break it short of stealing the original key, but it’s not practical to do that despite being the only provable encryption out there.

  • Not using the same password everywhere
  • Enforcing TLS on the mail systems
  • checking contents of a thread before forwarding / replying all
  • not using typical security questions / answers that can be found on google
  • deleting and scrubbing messages that are no longer needed
  • Not putting messages into writing that don’t have to be
  • Ensure that websites etc being used are running valid TLS (in general, but particularly critical when on a shared wifi)
  • Knowing that Extended Validation (EV) certificates don’t mean much and not to let them influence your trust of a service.
  • Don’t tweet about your secret plans / be conscious of what’s shared
  • Don’t share everything in your life on facebook just because you can; enable privacy settings etc on such services (consider Mastadon as an alternative if you want to get into the nitty-gritty)
  • I could go on but these are the easy ones off the top of my head

You mean there is no way one can be safe from state snooping?

What are you trying to hide?!? No seriously, the more one tries to evade BIG brother; the more they themselves a target.

Besides, once its left your smtp server there’s no guarantee whom in that pipeline is going to sniff it either at the ISP, the Backbone, or some looping BGP holes.

Now if one is concerned about security of their messages then obviously a good vpn with a trusted gss/pki authenticated email server that’s using TLS, SPF, DKIM, DMARC is going to go a long ways than most.

If one is really trying to hide from big brother; hide under a very large rock

Mind you I mean all this ingest but worrying too much about email security doesn’t build a lot of trust and trust is the starting point of all security.

Gonna stop you right there. A VPN will not, I repeat NOT provide any additional security for messaging.
Full stop

Attacks on communications involving static messages are not prevented by this since the messages themselves are already lacking forward secrecy. TLS already provides forward secrecy, and if everyone can hop on the VPN to talk to your server it doesn’t provide a better wrapper than TLS would.

A better solution for talking to your server is to simply Pin the certificate, i.e. you know the fingerprint because it’s your server and you know the certificate since you installed it.

You can’t use VPNs or pinning for recipients in a way that provides meaningful security, but you can muck things up worse pretty easily.

Also a point of clarification, these do nothing to prevent eavesdropping. These are purely for Non-Repudiation, i.e. verifying the mail did in fact originate from the server it claims to have (and that’s only on the recipient of the mail, not where it’s going to).

The extraordinarily unlikely attack since it basically breaks the internet everytime someone tries to pull it off :stuck_out_tongue:


I know this is a shortcoming, humans are the weakest link in the infosec chain, but this shouldn’t mean I can’t seek a solution :thinking:

I use mozilla send for sending files securely.

Would Thunderbird+Enigmail be an overkill? then I guess the person cannot be put under an Average person category. For me an average person is someone who atleast understands the importance of Passphrase or 2FA.

All I am seeking is Privacy. Privacy in communicating with my Attorney, Privacy in communicating with my Doctor, Privacy in sending a quote for an RFP etc…

Thats why I am trying to encrypt my communication at the source and decrypt it at target.

Right, and thats why my encrypted emails will be addressed to someone who I trust. And it is them who I trust only should read my message.

Encrypted e-mail with a third party (attorney, doctor, etc.) requires that their e-mail client will support the same method of encryption, that the recipient has a copy of your public encryption key, and that they know how to use that key in regards to their e-mail client and your emails. I don’t know about your doctor, but I’d have to train mine to do all that… and they’re probably not willing.

It is for this reason exactly that doctors have begun to use “patient portals” that include a messaging function. The portal is protected by TLS for in-transit encryption and prevents messages from being forwarded outside of the portal system. It’s not SMTP-based e-mail as we have all come to know, but it’s the de facto approach for secure messaging within the medical profession.

yes actually. The average person has very little reason to run PGP constantly. It’s a common screwed up piece of software with a lot of parts to actually get right (hint: enigmail+thunderbird doesn’t have safe settings out of the box) and fails often for users.

but again we’re talking about typical users, especially professional environments where things need to work reliably with people that aren’t technical. The biggest problem will always be those you interact with not being able to support PGP, or if they are using PGP not using it properly.

Good luck finding either of those that support PGP. Attorney maybe, but they’re more than likely going to just break the security model on their end since law firms tend to ignore technological best practices since they have too much else to juggle (on top of working with various firms they’ve been a rather disappointing set of targets in my pentesting work)

This. It’s what I was getting at with that liquidfiles suggestion; it’s not just documents, it’s also messages.
A lot of businesses just whitelabel LiquidFiles, Voltage, or Zix. Liquidfiles happens to have the best licensing for an individual user and is actually easy enough you can convince others to use it.

But how do you securely share the link to said files?

This is where things get really dicey.

1 Like

Gonna stop you right there. A VPN will not, I repeat NOT provide any additional security for messaging.
Full stop

Ok, here’s my sendmail server. root’s password is toor. Pwn it.

Please don’t assume one is advocating for the use of some vpn-as-a-service. Those are worse than the false dichotomy of "security that is tor.

But honestly; its been my experience that most people that even remotely ask “want to encrypt my email content and attachments” followed by “safe from state snooping”. Don’t even understand the OSI model nor the basics of what ssl/tls is or how it works let alone how to encrypt layer 3.

At that skill level it’s just simpler to explain “vpn” and “secure” the domain then provide educational material for them to learn from at their pace.

Also a point of clarification, these do nothing to prevent eavesdropping

Never said dkim/etc… was preventing eavesdropping. Frack if someone wanted to snoop they’re going to snoop.

Packet and message encapsulation is the only way to make it harder to snoop. And that’s the point.

The extraordinarily unlikely attack since it basically breaks the internet every time someone tries to pull it off :stuck_out_tongue:

Maybe if your not say AS701.

Hell it could be worse when AS3786 backdooring AS701 to do full packet capture on all cell phone internet traffic. I wouldn’t go into how long that was going on but it was a fun one to discover after finally getting that department to turn on logging and start using a SEIM.

That’s not a public IP address. No other public SMTP server can reach your sendmail server using that IP address rendering your sendmail server relatively useless as a two-way communications system. Surely you have an MX record pointing to a public IP that is translated across your firewall. That’s NAT, not VPN.

EDIT: Now, you might use a VPN for your mail client to traverse the firewall and submit outbound messages to your sendmail server, but that still doesn’t make your sendmail server protected by the VPN… it uses VPN to get around the other protections that might be in place. And once those messages leave your sendmail server destined for another, there’s no VPN there for transport or payload encryption.

You just tried to tell someone to use a VPN for message security, don’t try and walk it back as now some claim of using it just to talk to your mail server overall. It still doesn’t provide anything for that beyond the encapsulation that should already be there.

This is the wrong way to go about it; they are drastically different things and this sends people down the wrong path.
Re-read the original post I was replying to and explain why someone reading it that is not already an expert would get the wrong idea.

This is the opposite of what was done, instead a bunch of acronyms were thrown out including ones that have nothing to do with message security

The way it’s been included repeatedly in a thread on email encryption implies otherwise to those that are not familiar with it. TLS is all the encapsulation email needs until you hit levels of security where mail storage at rest has to be considered, or you decide that your CA is compromised at every moment (both of which call for PGP, S/MIME, or similar)

It’s caught a lot faster than that on communities as a whole; the fact that 701 (Verizon) doesn’t have a 24/7 contact for their NOC that actually works is their problem to ignore the world burning. It wasn’t for want of a SIEM

As for 3786 they’ve been involved in route leaks through HE, but no one has identified anything malicious from them AFAIK.
Route hijacking is extremely noisy and alerts the BGP community as a whole, not just the target. There are a large number of groups that do nothing but watch the BGP routing table for anomalies, or they operate on such scale that they have to watch the full routing tables anyway.
It additionally still does not break TLS; so between the noise and fact it doesn’t do anything to help break TLS between mail servers it’s not particularly valuable in the case of email.