Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I do not get why everyone thinks that encrypted email is GPG.

S/MIME is supported by almost all email clients.

S/MIME is far less of a pain (but still some pain and could be improved).

It has a model of how to verify that keys belong to the right person, that actually works in practice in contrast to GPG where you basically have to verify keys by hand (adversarial CAs are a problem, but probably only for a tiny amount of people).



S/MIME works fine. Key management isn't a big of deal as many make it out to be. You can pin your key to your linkedin profile or facebook or whatever. Or have a one-time plain-text email asking "Hey, whats your public key?" Right-click, import. Call them on the phone if youre worried that one email was fake.

The problem with HN is that its mostly web-dev startup scene and college students. They've never worked in a company that took security seriously. S/MIME implementations are everywhere in these types of companies and work fine.

If you wanted encrypted email right now you could have it trivially. The problem is that most people don't value it yet. Considering all the hacks and leaks we're seeing, I suspect encrypted email is going to be part of HIPAA or PCI in the next ten years. It makes no sense to use plaintext email in a business setting.


I've tried to collect some S/MIME resources (corporate users, software support etc.) in some GitHub gists available at http://smime.io/ - however the recent "ousting" of StartSSL hurt the (free) S/MIME adoption for individuals and neither LE nor Google CA are an alternative yet.


My thoughts exactly.

In an industry niche where people love the phrase "perfect is the enemy of good", S/MIME is better than GPG/etc because its actually somewhat useable out of the box for people.


a) The key management UX is even worse than GPG, at least IME.

b) If you're willing to trust the CA system the advantages of using email rather than any transport-encrypted messenger (e.g. facebook messenger) seem decidedly marginal


You control which CAs you anchor your trust to locally. Additionally, the encryption part isn't tied to the CA system -- you encrypt directly with the public keys of your recipients. You can use the CA system to validate that the public key belongs to someone validated by some attributes -- certificates are used for this.

The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use S/MIME heavily.


> You control which CAs you anchor your trust to locally.

Theoretically, but doesn't it tend to use the same OS infrastructure as HTTPS?

> The US Federal Government (FPKI) and US Department of Defense (DOD PKI) use S/MIME heavily.

Indeed, but they are in a position to trust the US government (and more generally the international governmental system).


>Indeed, but they are in a position to trust the US government (and more generally the international governmental system).

Not sure what trusting the government has to do with it, it has to do with trusting the CA system that's set up on the computer.


> Not sure what trusting the government has to do with it, it has to do with trusting the CA system that's set up on the computer.

Almost all computers ship with a bunch of governments set up as trust roots. It's not impossible to change this, but it's impractical for all but the largest organizations.


Speaking of which, any decent S/MIME issuer/CA out there? I used StartSSL but there is some stink around them.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: