Email Encryption
October 14, 2008 9:25 AM Subscribe
Help in briefly listing E-Mail Encryption options. Is this Wikipedia list of protocols a good start?
I give workshops to government agencies on records management and we are increasingly getting people asking about sending confidential information via email. Our answer to that historically has been "don't send confidential information by email." But I'd like to add one slide to our presentation perhaps listing some options or protocols.
For our presentations we keep IT things very, very basic. For example we often say to have reliable electronic records: "make sure your network is secure. Talk to your IT people about this."
What I'm looking for is a list of four or five options and say "Ask your IT people about this." If the person takes that list to their IT person, I don't want us to look like COMPLETE morons. I'm comfortable with the IT person saying "these two things suck" or "they left something out." If I make a list I want to make sure they are the same things: protocols or programs or standards.
I tried googling and seemed to mostly get places selling encryption software. I would probably also add something to the slide like "many off the shelf products available."
If you haven't figured it out, I know almost nothing about this. Looking at this previous question answer, is that basically what it comes down to: PGP vs S/MIME? Also found this question, any answers in there that pop out as particularly useful?
Thank you!
I give workshops to government agencies on records management and we are increasingly getting people asking about sending confidential information via email. Our answer to that historically has been "don't send confidential information by email." But I'd like to add one slide to our presentation perhaps listing some options or protocols.
For our presentations we keep IT things very, very basic. For example we often say to have reliable electronic records: "make sure your network is secure. Talk to your IT people about this."
What I'm looking for is a list of four or five options and say "Ask your IT people about this." If the person takes that list to their IT person, I don't want us to look like COMPLETE morons. I'm comfortable with the IT person saying "these two things suck" or "they left something out." If I make a list I want to make sure they are the same things: protocols or programs or standards.
I tried googling and seemed to mostly get places selling encryption software. I would probably also add something to the slide like "many off the shelf products available."
If you haven't figured it out, I know almost nothing about this. Looking at this previous question answer, is that basically what it comes down to: PGP vs S/MIME? Also found this question, any answers in there that pop out as particularly useful?
Thank you!
Best answer: There's a third set of options, which is services where your message isn't encrypted per se but it never leaves a secure server (except to be read) and everyone talks to that server over an encrypted channel. For a kind of goofy example, a web-based forum which only accepts HTTPS connections. And there are kind of hybrids like Hushmail.
The Wikipedia article is slightly muddled, I think; if you're presenting to someone, I think it's worth making a clear distinction between hop-by-hop encryption (most mail-related protocols support some sort of SSL/TLS mode) and message encryption (PGP, S/MIME). Hop-by-hop encryption can reduce your exposure a lot and is easy to deploy, but you have to trust every mail relay and every mail server that the message might end up on; you have to trust them not just today, but also not to expose some stored data in the future. Its big advantage is that the sysadmin can probably enable it with a few lines in a config file and the users don't have to do anything special. Message-based encryption, on the other hand, allows you to very tightly control who might have access to a given message, but it puts a lot more burden on the user, which in practice can translate to general frustration and lost mail if someone forgets a passphrase. (But that's what key escrow is for.)
As for things missing from the article: on the hop-by-hop side, I guess you could add VPNs, IPsec, and the like. On the message encryption side, I think S/MIME and PGP are the ones to list; they're widely used, they're not snake oil, and both have multiple inter-operating implementations, both commercially-supported and free.
posted by hattifattener at 9:53 AM on October 14, 2008
The Wikipedia article is slightly muddled, I think; if you're presenting to someone, I think it's worth making a clear distinction between hop-by-hop encryption (most mail-related protocols support some sort of SSL/TLS mode) and message encryption (PGP, S/MIME). Hop-by-hop encryption can reduce your exposure a lot and is easy to deploy, but you have to trust every mail relay and every mail server that the message might end up on; you have to trust them not just today, but also not to expose some stored data in the future. Its big advantage is that the sysadmin can probably enable it with a few lines in a config file and the users don't have to do anything special. Message-based encryption, on the other hand, allows you to very tightly control who might have access to a given message, but it puts a lot more burden on the user, which in practice can translate to general frustration and lost mail if someone forgets a passphrase. (But that's what key escrow is for.)
As for things missing from the article: on the hop-by-hop side, I guess you could add VPNs, IPsec, and the like. On the message encryption side, I think S/MIME and PGP are the ones to list; they're widely used, they're not snake oil, and both have multiple inter-operating implementations, both commercially-supported and free.
posted by hattifattener at 9:53 AM on October 14, 2008
s/mime and pgp are the only email encryption options that I have seen employed in the enterprise. S/MIME is good if you have a centrally managed PKI and good certificate management practices and procedures, and everyone who will be sending/receiving encrypted email can get a cert from the pki. PGP/OpenPGP/GnuPG is good if centralized management for all participants is not possible, and everyone is doing their own thing as far as email clients/servers go. PGP enterprise has some central management capabilities, but it is not as slick as PKI+S/MIME with exchange/outlook.
posted by rye bread at 9:59 AM on October 14, 2008
posted by rye bread at 9:59 AM on October 14, 2008
(Also, wrt PGP/GPG/etc.: the original freeware was called PGP; there's now a company called PGP Inc. selling a program called PGP, as well as a GPL'd re-implementation called GnuPG or GPG. The actual message formats / protocol / algorithms are now standardized under the name OpenPGP. I refer to the message format as PGP, though if I wanted t be utterly pedantic and also be clear that I'm referring to the format and not any particular implementation or product, I might use the term OpenPGP. Regardless of all that, the encrypted messages all start with the text "BEGIN PGP ENCRYPTED MESSAGE", so calling it PGP seems reasonable to me.)
posted by hattifattener at 10:01 AM on October 14, 2008
posted by hattifattener at 10:01 AM on October 14, 2008
Response by poster: Thanks everyone. Where I'm at now:
Points to Consider with Email Encryption
1. Inter-Enterprise or Intra-Enterprise
2. Message Encryption or Never Leave a Secure Server
Encryption options depend on how centrally managed your email system is.
Talk to your IT people.
The above is what I'm looking at for a slide on this subject. We try not to get into acronyms too much. I figure if they go to their IT person hopefully he'll know about the S/MIME or PGP. Like I said, we keep our IT info very general.
In the same audience for our presentations there can be a small town clerk, big city police chief, network admin who drew the short straw, and a Register of Deeds all sitting in the same row. Some of them have enterprise-wide email systems with huge budgets, some of them use yahoo for their email. So you can see why we deal in generalities.
posted by marxchivist at 10:41 AM on October 14, 2008
Points to Consider with Email Encryption
1. Inter-Enterprise or Intra-Enterprise
2. Message Encryption or Never Leave a Secure Server
Encryption options depend on how centrally managed your email system is.
Talk to your IT people.
The above is what I'm looking at for a slide on this subject. We try not to get into acronyms too much. I figure if they go to their IT person hopefully he'll know about the S/MIME or PGP. Like I said, we keep our IT info very general.
In the same audience for our presentations there can be a small town clerk, big city police chief, network admin who drew the short straw, and a Register of Deeds all sitting in the same row. Some of them have enterprise-wide email systems with huge budgets, some of them use yahoo for their email. So you can see why we deal in generalities.
posted by marxchivist at 10:41 AM on October 14, 2008
Your slide sounds accurate and concise, yup. If you can impart the difference between "regular mail sent/read via secure channels" and "secure (encrypted) mail that can travel over any channel", you're achieving a lot.
posted by rokusan at 11:22 AM on October 14, 2008
posted by rokusan at 11:22 AM on October 14, 2008
Best answer: That sounds like a reasonable summary, marxchivist.
It might be too advanced or general a point for a powerpoint slide, but something that is really important to consider when you're looking at crypto (or security in general) is "understand your threat model". What are you trying to prevent? What are you trying to ensure? Who is your adversary— external attackers, and if so how well funded? Internal attackers, and if so how well placed? Internal mistakes? (Don't underestimate the importance of that last one.) The people you're presenting to might not be able to answer these questions directly, but it would be nice to hint to them that whoever's in charge of implementing their email security should at least be familiar with the concept of a threat model and have given some thought to what their organization's threat model is. Especially in the case of crypto, it's easy to get caught up in defending against crazy scenarios involving KGB network taps and ignore the possibility of someone leaving their laptop on the bus.
posted by hattifattener at 8:03 PM on October 14, 2008
It might be too advanced or general a point for a powerpoint slide, but something that is really important to consider when you're looking at crypto (or security in general) is "understand your threat model". What are you trying to prevent? What are you trying to ensure? Who is your adversary— external attackers, and if so how well funded? Internal attackers, and if so how well placed? Internal mistakes? (Don't underestimate the importance of that last one.) The people you're presenting to might not be able to answer these questions directly, but it would be nice to hint to them that whoever's in charge of implementing their email security should at least be familiar with the concept of a threat model and have given some thought to what their organization's threat model is. Especially in the case of crypto, it's easy to get caught up in defending against crazy scenarios involving KGB network taps and ignore the possibility of someone leaving their laptop on the bus.
posted by hattifattener at 8:03 PM on October 14, 2008
Response by poster: Thanks everyone. That was very helpful in helping me to wrap my brain around some of the questions about this. We gave the workshop twice today and none of the IT folks laughed at my encryption slide.
posted by marxchivist at 5:12 PM on October 15, 2008
posted by marxchivist at 5:12 PM on October 15, 2008
This thread is closed to new comments.
For example for an organization that has deployed Lotus Notes for e-mail, encryption of messages between employees is pretty easy as the public key infrastructure needed to do encrypted messages is already setup in every Notes deployment.
posted by mmascolino at 9:46 AM on October 14, 2008