Sending Secure E-Mail?
-
These are some of the software and services that support encrypted mail with GPG/PGP inside the mail client.
https://www.openpgp.org/software/It's an open standard: https://tools.ietf.org/html/rfc4880
-
@Pete-S said in Sending Secure E-Mail?:
These are some of the software and services that support encrypted mail with GPG/PGP inside the mail client.
https://www.openpgp.org/software/It's an open standard: https://tools.ietf.org/html/rfc4880
The problem is, is that for GPG/PGP to work, you have to exchange keys outside of email, but the requirement in this case is to do it all within email. So that doesn't work. The system admin can always get the key out of your email and open whatever has been sent. It ends up doing nothing more than TLS already does, but with a lot more manual work.
If they could exchange keys, of course, but there is a reason that we'd already pointed out that this didn't meet the criteria right away.
-
@scottalanmiller said in Sending Secure E-Mail?:
you have to exchange keys outside of email
Sorry Scott, but that is completely incorrect. The public key is public.
-
@scottalanmiller said in Sending Secure E-Mail?:
The system admin can always get the key out of your email and open whatever has been sent.
Completely incorrect as well. The public key can only be used for encryption, not decryption.
-
@scottalanmiller said in Sending Secure E-Mail?:
It ends up doing nothing more than TLS already does, but with a lot more manual work.
Completely wrong as well. TLS is just transport encryption. When it's not in transport, it's not encrypted.
-
@scottalanmiller said in Sending Secure E-Mail?:
If they could exchange keys, of course, but there is a reason that we'd already pointed out that this didn't meet the criteria right away.
It's because you are thinking about symmetric encryption.
From wikipedia:
Symmetric encryption
"The overarching problem with symmetrical cryptography, or single-key cryptography, is that it requires a secret key to be communicated through trusted couriers, diplomatic bags, or any other secure communication channel. If two parties cannot establish a secure initial key exchange, they won't be able to communicate securely without the risk of messages being intercepted and decrypted by a third party who acquired the key during the initial key exchange."Asymmetric encryption
Public-key cryptography uses a two-key system, consisting of the public and the private keys, where messages are encrypted with one key and decrypted with another. It depends on the selected cryptographic algorithm which key—public or private—is used for encrypting messages, and which for decrypting. For example, in RSA, the private key is used for decrypting messages, while in the Digital Signature Algorithm (DSA), the private key is used for encrypting them. The public key can be sent over non-secure channels or shared in public; the private key is only available to its owner. -
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
The system admin can always get the key out of your email and open whatever has been sent.
Completely incorrect as well. The public key can only be used for encryption, not decryption.
Oh, right, okay, having a "duh" moment. So you can send your public key via email, and ANYONE can send you an encrypted email, but ONLY to you. Because you have the private decryption key.
You are right, I follow now. That could work.
The question would be... if they aren't allowed to communicate through any means but email, while we don't know why that is, it feels unlikely that they will be allowed to request that the recipients send them their public key or even generate one. It's hard to imagine asking recipients that you aren't even allowed to call to do this. But in theory, you could.
-
This is what PGP encrypted email looks like. Like all email it's just plain text. Before this section is the usual email headers. So the "To:" and "From:" and "Subject:" is not encrypted but the email content itself is.
This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156) --xhndWJKlxj2H7EcRFNi37V5EBuMbJO6xj Content-Type: application/pgp-encrypted Content-Description: PGP/MIME version identification Version: 1 --xhndWJKlxj2H7EcRFNi37V5EBuMbJO6xj Content-Type: application/octet-stream; name="encrypted.asc" Content-Description: OpenPGP encrypted message Content-Disposition: inline; filename="encrypted.asc" -----BEGIN PGP MESSAGE----- Version: GnuPG v1.4.12 (GNU/Linux) hQEMA6dGE3LaIUOQAQf8DGIYe/G72AkcY0M3+s2xfbe+JNax3gpPXtDUpxQVPbIF emRbZZUgOR5NVd7oZ+/ezO2r455HVG2Ar12cA88tk9i86XOOFAhaO1Ib7nTpKAS+ Um9EbsfO1kqS1qmIJIaDOV6hSfSssxDVEj5SMhvDhH/s3As/0Xo3q3+5CqahOxPF /xeanqndpWqyusmJTQzmE3RZhqtErIB9oaMzBNyx1KZ3fhrxGdsSX1wNYpalelGu wJBKZGsfxr0BPL+jb/UDXLNtf1QdNLkSTLpqtHYb8aNNLaDOTMo2CnLKaqSMpAbR e1sBAYxqPchwMPKT9zo60Z+OqRUcUC1dTi6SahiKD4UBDAPaVPPT71S0wgEH/iIC 0eh4w7flugfSP/pBylcCb3Ud3MyjRmHEepG90kkFa/PP2Wxybe7R/080Sj5910Es BZBDn8f/Eg6w1/VNp+FMc/28NU460Gkw0TSWjWSNpwl0W3TMgszvS+ug+P3uxyfx JH00ho+59nRJPaxrDX4rIZl5/1DRVhjWudGLzEU9sAg7/CTusloBhsP2wWXgMXxP mwF69uNptRmAgoVjTOBJgfC3wJO3Vmt8Ml8VLV57lL3T6KbRuiYABNICD+2eSgUc bY6xo4Cvz/EINKTHWzTiSaSRrVkf6J6QMRVFNfnCMW4esGfY+W2bAysHfyD0w754 pOhKx+eewM9qUV9JRjrS6gFDgkjNq7G/ps9O6RaY8MZ2TYFapEdDSjvxzDbBjRqL Zp3gkIC5TVhSA2IkgDa0ddm9+kW7oKsyVtW6YunsUGALs9WZthY6cAOThVT3JmOb t0M3lNtlByzqWYKuzP1ZJKkGui1Vi1K0OPRZ1cSXhwsYzQD72bAqJxh2SLVcqix2 GpybtuR/K6vHonDCj6F/ISKCSTnJZSptPd81H0DLU3AubHhwRs5hkvsAAhr0XcXW m57s7CsEUVSeowXfT+qSYglB7UaNjKkkhPSGhxOIlEKcPndNH4kElKknghesu17Q 3+ajidIJTAe6oZ61t1OOMOU2Qw2a9H7OvYHWTWSl5RhrcDTTrTlkeWavmZwa3Nsa 9OH1N5m4EzbcYGTJdZOVTZM4ViX1XHNHENkdAUHItmrs7DqXSxuUrQGJ0W6IYRfV 3A+IRkTvd6wrA9ju5J0RqF0xvhHr4gXAUgiVau0Fkxo3UiTvonpe5Jvm2yRA9v/x YAefEXGSmGpLfAbwteT6BSViYhg/Mwi5uoSxwbUUy43uBVFXo9cDqIWlATp/GvgU pxpoflT9RdyhugoKyFJ+3fCv32Rm+G/tJKxN5snnoEeIFSj5FVgPJKyrcyiKwJg2 wvE/OCg/+Nvqyx5LnVna2N5mOfO3fqZeBpq2bnH1Auq57s1ftFJGC+7IxWZKZUFa Tbl/KpjIhLQojSiThB+yg5cMfnZ0+xYxD8EfWFuiLWgZwQJO8CJs62QXzlP6qwjm g13UFfzpa+994lcRfZ1UzwEXb6Mk6NS/2nwkkDrztAhKKJtLNGx/R4wC9qloi4gl 0FDQcmOBkSwYJXxUzIxu8WCKVrLDFHKyI0eG4o4h3swUnAgGpvmX3Z7ECFanDY0s jlKG7gY7zcagAycsrVVl66tAFlPAGlTHWM43RrgvYKudlImnJBp2ZPYsG4xqn7cR ED/RhDuAGRLXy+HzL028TSJUiIet48eOD2zAmMd8EQpuT4QBFs+KL9lsTzmbCCcH lpJJxReWmAi3501zcvJUaOsfeG+prhlZg3WSIboisu5s82tCl4SURztIRwfTGl3a IjxENi16vchVfAIIDqwAHFyQrA5fmgjsASFukf+HArOezksxd9EQmgeQYUc1Au98 h0zphTEkvkI4jlwP2upUXkYMTRZj5Rqr0US9T+TkArtbI/f4NDtKEfzlDv2v63p/ UwmSetfR7g0U1OMZbogewb1PM8vGorneUv+tKU7feTZhWmMe6qyWVpsWO1du9i3k LlaWS6m72DCjXuiAl1X3BApWIdQxgeQdfQ/QxM1Z1Vk2ooBIzARzQ+rZa2A9xzVh x+s4wZOEAD0sFzYoMr2OZMfA5dySwaz/5/aNR+vL3DbpLEvAnQAj6wZLoHTKuR3N Ofw0DvTZDVd1yYPTkG28L0B42ZySGfFSzlebJHcuNCH2mLgUb0XJiVO5s3kaADqE E2nQzrdHgBjodVGO+bnfXlzEySVVTSVQt/yXx7YhxBk+MIXq1JEwAFYLS745sgZc 2lQDhvCcT327mgV5h+CHwYbQM1ZGOrPnia3RzSWTPNiphBqcZe129fD+3zlbdrkC spcsSGfK1OysgGsectehQ6LjE2eASktzxQmS8ViNxnoum4Y2Ce60ED49M1ApGJ1J MRaJdcgRkLEihA/K6PndHnjfawQwP2kQX/j9q4vCNfLCm+SP6SdLsWRSQuvRGT4q +Fx9+qX+znjWVOYZzeIrtv64a0lJtJGrnaPoKez5yR0TN/r9qv6PB/3N/np6bLQG 0u0col+lnPgxVC8oxbR/6Ev9sAfVmHUw04IpO9QBw5zaLapIlMdL1TonzxVs552F LFo7fAcjVc7E/cxfYrvXkBG5PhNHbMDsYaVA5XyvOkNhv0vkqyPatK0BIyttVy+F 0DSAdFB2SVlEkcKLPd6ciY5wpufwH63wnj80TpS4jZJl/0DMLkcpiU6xuYrN5Ibs 9UVTpcT/J7/jvbPaCpDmHzaGNDOVCcpS/YGrla6nKY14lwI/XHXrF/5MFGVki/Hp sIbNWcbRTQDzNlcp2Z7D0APArt7HN4AwiuEo/GXMC8sKAJjIIAg4mjhbBlEmIvLh z65wNWwqqmYvuerIMDYlIvPry749CSrJ2Q8H4LfA3nRl0gY/twW5O2IEoHnhx/x/ vvJCy+WRJnUaMvCR/JI2Pt2ZkEUFLDe1t5TGlrYhEP5G6m85AXuaSCFHZNJ8TZB8 DodR7quOLAbTLGmCpXrMfKpyaczbjj8hnqstT7/sCo1M0LHbBdFPpDcVmF0H1CW4 10Vx/NdrY998eE84ryocgSdgkloTiUeMYUwIFYo2FwnfkXe6/3+5RATlr17sCrXE kaEp73F/FhSeN18d3baiCcvWfkVW2hmyM48AgZRcDzjIOXeQnqwZ03YB1nt4DLK8 6jGivw+1JFVjbDonodGSvZX5eirTR+2xQiXBvZuhlpmLNY9Y0T8YtScicc8eQ2m7 YhSw07/vawW+yg89po/MIj2WL5/m2EmfRxQWL6phv/Ee4JUogvmOiKbgKG/W84+v 4Q== =m2A7 -----END PGP MESSAGE----- --xhndWJKlxj2H7EcRFNi37V5EBuMbJO6xj-- -
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
It ends up doing nothing more than TLS already does, but with a lot more manual work.
Completely wrong as well. TLS is just transport encryption. When it's not in transport, it's not encrypted.
Yes, I understand that point. I was thinking that they could not send the encryption key first, leaving it as open. But, if the requirement allows the recipient to do all the work to set up their own GPG, then this could work.
I wrongly just assumed that if they could do this that they could do any number of things so having the recipient set up GPG / PGP wasn't an option. But that was an assumption and not actually stated.
-
@scottalanmiller said in Sending Secure E-Mail?:
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
The system admin can always get the key out of your email and open whatever has been sent.
Completely incorrect as well. The public key can only be used for encryption, not decryption.
Oh, right, okay, having a "duh" moment. So you can send your public key via email, and ANYONE can send you an encrypted email, but ONLY to you. Because you have the private decryption key.
You are right, I follow now. That could work.
No problem. I'm not a crypto guy but we used PGP encrypted email for many years so I know the basic principles.
-
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
The system admin can always get the key out of your email and open whatever has been sent.
Completely incorrect as well. The public key can only be used for encryption, not decryption.
Oh, right, okay, having a "duh" moment. So you can send your public key via email, and ANYONE can send you an encrypted email, but ONLY to you. Because you have the private decryption key.
You are right, I follow now. That could work.
No problem. I'm not a crypto guy but we used PGP encrypted email for many years so I know the basic principles.
I've used it, but I was adding in the incorrect assumption that everything had to be done only on the sender's end. Which if you did that, encrypting with PGP and sending the key with it, anyone who intercepted would be able to read. But if the recipient can send the key too, then yeah, obviously that works great.
-
@scottalanmiller said in Sending Secure E-Mail?:
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
The system admin can always get the key out of your email and open whatever has been sent.
Completely incorrect as well. The public key can only be used for encryption, not decryption.
Oh, right, okay, having a "duh" moment. So you can send your public key via email, and ANYONE can send you an encrypted email, but ONLY to you. Because you have the private decryption key.
You are right, I follow now. That could work.
No problem. I'm not a crypto guy but we used PGP encrypted email for many years so I know the basic principles.
I've used it, but I was adding in the incorrect assumption that everything had to be done only on the sender's end. Which if you did that, encrypting with PGP and sending the key with it, anyone who intercepted would be able to read. But if the recipient can send the key too, then yeah, obviously that works great.
It's pretty easy to install and use nowadays, especially if you are just a couple of persons. You just install the add-on needed depending on your email client. Then you have to tell it what you want your passphrase to be and it will create your public and private key for you.
All you have to do then is email your public key to whomever you want to be able to receive secure emails from. And they'll do the same.
When you receive a secure email you have to enter your passphrase to read it.
-
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
@Pete-S said in Sending Secure E-Mail?:
@scottalanmiller said in Sending Secure E-Mail?:
The system admin can always get the key out of your email and open whatever has been sent.
Completely incorrect as well. The public key can only be used for encryption, not decryption.
Oh, right, okay, having a "duh" moment. So you can send your public key via email, and ANYONE can send you an encrypted email, but ONLY to you. Because you have the private decryption key.
You are right, I follow now. That could work.
No problem. I'm not a crypto guy but we used PGP encrypted email for many years so I know the basic principles.
I've used it, but I was adding in the incorrect assumption that everything had to be done only on the sender's end. Which if you did that, encrypting with PGP and sending the key with it, anyone who intercepted would be able to read. But if the recipient can send the key too, then yeah, obviously that works great.
It's pretty easy to install and use nowadays, especially if you are just a couple of persons. You just install the add-on needed depending on your email client. Then you have to tell it what you want your passphrase to be and it will create your public and private key for you.
All you have to do then is email your public key to whomever you want to be able to receive secure emails from. And they'll do the same.
When you receive a secure email you have to enter your passphrase to read it.
Writing this I think the best way to use this for ordinary business use is to only send encrypted email when you are sending something sensitive, like passwords or stuff like that.
Problem with encrypted email (and also it's strength) is that you can't read it if you don't have your private key and passphrase. But it makes it complicated reading email on different devices and software unless you copy your private key everywhere and enter your passphrase on a number of insecure devices. Which defeats the security aspect of it.
So it works best on desktop clients and if you only encrypt when really needed, you are not much affected by the drawbacks. If you try to read an encrypted email on a devices that doesn't support it you'll just see an attachment that is just gibberish as my earlier post shows.
-
@JasGot
Is this all inter-company email you're talking about or is it your customer sending e-mail to outside parties?I was under the assumption you were talking about your customer wanting to send secure email to 3rd parties.
If that's the case, it's not as simple as having the 3rd party set up PKI solution and giving everyone in your customer's company a public key so they can encrypt emails to send them (unless they already have that set up).
If the sole goal of all of this is to keep the email systems administrators and computer client admins from obtaining and reading any email, then the ONLY options are either to encrypt the emails themselves as in GPG/PGP pki on the receivers end, or a third party that uses some other means to verify identity before allowing the recipient to view the email similar to how your bank may send secure communications to you.
In the past I set up a global PKI solution as a requirement that did just this, and also made available a solution that could distribute a certificate to any 3rd party that needed one which would allow a user in the company to then send an encrypted email to that recipient once the recipient sent a copy of the public key. This worked well, as I had set up some good instructions users in my company could use to help get the 3rd party recipient set up.
Also, keep in mind this will only work if the email clients support encryption. Clients like Outlook and Thunderbird do. OWA can if you use IE plus some MS plugin.
-
@Pete-S said in Sending Secure E-Mail?:
Writing this I think the best way to use this for ordinary business use is to only send encrypted email when you are sending something sensitive, like passwords or stuff like that.
For sure, it makes way too many things way too much of a pain.
-
Our customer doesn't want the city's bank account and routing info transported through e-mail. He was willing to do it if we could come up with a way that would guarantee it could not be read in transit.
He understands the sysadmins at each end can read it, and he understands that he has no control over what happens after it arrives at the recipient.
He, like me, has used systems that "appear" to provide a little more protection. ie; when my broker wants me to see a document, I get an e-mail that takes me to a web port. Once I log in, I can view the document.
The problem with this type of system is that a) we don't know if the employee at the state can visit any of these sites. b) we don't know if the employee at the state is willing to put forth the effort.
As for the PGP idea, we don't even know if the state employee is using an actual e-mail client.
So for know the customer really only has two options to alleviate his concerns: 1) continue sending by usps and wait a month or more for action, or 2) send an encrypted file as an attachment and HOPE the receiving mail server allows it, and HOPE the recipient will call and ask for the password.
With the possibility of little or no cooperation at the receiving end, the customer is basically SOL.
-
@JasGot said in Sending Secure E-Mail?:
Our customer doesn't want the city's bank account and routing info transported through e-mail. He was willing to do it if we could come up with a way that would guarantee it could not be read in transit.
I do believe there is another option, now that you have changed the rules to the bolded above. TLS, TLS gives you this. And this is something you can confirm beforehand.
-
@Dashrender said in Sending Secure E-Mail?:
@JasGot said in Sending Secure E-Mail?:
Our customer doesn't want the city's bank account and routing info transported through e-mail. He was willing to do it if we could come up with a way that would guarantee it could not be read in transit.
I do believe there is another option, now that you have changed the rules to the bolded above. TLS, TLS gives you this. And this is something you can confirm beforehand.
If by confirm you mean refuse to send the email if the recipient server rejects the
STARTTLSthen yes. -
@JasGot said in Sending Secure E-Mail?:
Our customer doesn't want the city's bank account and routing info transported through e-mail. He was willing to do it if we could come up with a way that would guarantee it could not be read in transit.
That's totally different than what was asked. Of course normal email cannot be read in transit. So all you have to do is enforce TLS instead of letting it be opportunistic and ta da, problem solved.
-
@JasGot said in Sending Secure E-Mail?:
With the possibility of little or no cooperation at the receiving end, the customer is basically SOL.
No, actually they are in great shape.
Because...
- Any system that isn't using TLS for their email you have way, way bigger concerns and you shouldn't be talking to anyway.
- You simply set to enforcing and everything is guaranteed to meet your needs.
It's a great situation and why most of us have no issues like this, because TLS meets the needs.
