I am doing my best to understand how this works. I read numerous articles, but always get confused.
From my limited understanding, both sender and recipient must have their client installed with a key/certificate provided by a certificate authority. But how do the mail clients of both the sender and the receiver use these certificate ?
Here a concrete example of something that confuses me, from Wikipedia (https://en.wikipedia.org/wiki/S/MIME):
While it is technically possible to send a message encrypted (using the destination party certificate) without having one's own certificate to digitally sign, in practice, [...]
So, the sender mail client should be able to encrypt a message using the recipient certificate. In practice, how does the sender mail client infer, just from the mail address of the recipient, what is the recipient certificate ? Does the mail clients of the sender and of the recipient "ping" each other and exchange somehow this information ? Is it inferred from the domain of the email address ? Or are the users of the email clients expected to exchange before hand these information ?
You are asking several questions. That's probably because you are confused. Let me try to sort things out.
For encryption purposes
the sender uses the recipient's public key (from the recipient's public certificate) to encrypt the email
the recipient then uses their own private key to decrypt the email
For signing purposes
the sender uses their own their own private key to sign the email
the recipient then uses the sender's public key (from the sender's public certificate) to verify the signature
To exchange public certificates
Alice sends a signed, but not encrypted email to Bob
the signature includes Alice's public certificate
Bob can extract Alice's public certificate from the mail
Bob trusts Alice's certificate because it was signed by a trusted authority *)
Bob can now verify the signature including the certificate
Bob can now send encrypted email to Alice
*) Every operating system comes with a load of pre-trusted certificate authorities
Bob then also shares his own certificate by signing the email when replying back to Alice. After that, encryption is possible in both directions.
Other
The quote from Wikipedia addresses a different aspect:
If Alice sends an encrypted email to Bob, Alice uses Bob's public key to encrypt the email, so only Bob can decrypt it. But this also means that Alice cannot decrypt her own email (that it stored in her 'sent' folder)!
It would be a severe security breach to store the email unencrypted in Alice's 'sent' folder, so what can be done? The email can be encrypted for both, the recipient Bob as well as the sender Alice.
Now how can one email be encrypted with multiple encryption keys?
The email is actually not encrypted with Bob's key, but instead
a random key is chosen to encrypt the email contents
the random key is encrypted with Bob's key and added to the message
the random key is also encrypted with Alice's key and added to the message
Then to decrypt, the random key is decrypted with the recipient's private key, then the email contents is decrypted with that decrypted key.
The random key is called the 'content encryption key' or CEK, while the personal keys are called the 'key encryption keys' or KEK in this scenario.
There's yet another reason to use a CEK - which has to do with symmetric encryption being much faster and more scalable than asymmetric encryption - but that's another story that shall be told in an answer to another question.
If you have already exchanged certificates with somebody and you already encrypt emails, do you sign the following emails anyway/again? What is the accepted standard procedure for this? Where is this described?
The purpose of a (cryptographic) signature on an email is to prove that the sender is who the sender claims to be, and not some one who found an open relay mail server to forge a From:. Therefore one would sign any message that one wants to have proof of origin on, which one presumes would be all messages.
Encrypting means that only the intended recipient(s) can read it, but doesn't say anything about who sent it. So, great, an encrypted mail had an attachment... still throwing it in the trash. Or, I might have a policy to not decrypt it at all because it's bigger than 100kb and unsigned (I don't know of any client that has policies like that, but they're not unreasonable).
Let's picture the following scenario:
Bob talks Alice using HTTP/HTTPS
Bob want Alice to send him some data ex: /rest/getAllItems. + some token auth
Eve intercept the packet and send it to Alice without even knowing what it contains
Alice verify the request token contenent (signature etc...) and send the respence to Eve instead of Bob.
How to prevent such scenario from happening.
I have two users, Joe and Jill, on an email where they are both recipients in the to field. Using IMAP and their respective user oauth tokens, I poll GMail and get this email. What fields will be unique to their user and what won't, e.g. will the email's message_uid be different for both of them or the same?
The message bodies themselves will be the same. The UID and ID will likely be different, but not necessarily. The message headers will be the same, except for possibly the Received headers.
There is completely reliable way of detecting this. The usual way of dealing with this is to work on unique Message-Id header which is supposed to be unique, but in real world, you will sooner or later came across a pair of messages which are vastly different, yet share the same Message-Id.
Tricks like hashing the raw, undecoded message body tend to work as well (or at least until you hit a user who happens to use a mail server which changes the MIME encoding of such a message).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I have to send sensitive information (name, address, social security number etc.) collected from a website, that has been entered by a user, to an e-mail address.
What is the best course of action to make the information secure and easy to extract on the receiver side?
Edit: I will be using ASP.NET for the website, not sure what it has for capabilities on this matter.
Edit: If I decide to store the information in a database and just send a mail when a new entry has been made, would this be better? And create some secure way to dump the information instead.
The best course of action would be to run the other way, fast. Redesign your application so that it doesn't enable identity theft.
You can use S/MIME or PGP to send secure email to most non-Web email clients, but it takes a lot of set up either way: the recipient has to have a certificate, and you have to get the right certificate for each recipient.
As an example of a better design, consider one where the recipient is mailed a notification, and then returns to the web site to view the information after authenticating securely over SSL.
While it helps to reduce the complexity of the system needed by the recipient, the bigger win is that it strengthens control over the distribution and retention of the sensitive information, and aids in auditing the access to that information. Sending someone an email makes it that much easier for them to store it unsafely, forever, or forward it to unauthorized recipients.
Encryption, Encryption, Encryption!!! Nothing else :)
Put the data into an encrypted attachment of the mail. The attachment can be any format you like. This will make parsing on the other side reliable. You can use any codec which ASP.NET supports, so you can choose anything that the other side can read.
Sadly, I don't think there is a practical solution for you here if you are taking about a mailto: URL.
The only secure way to send things over email is encryption. You can use PGP or S/MIME, but neither of those are easy to deploy for arbitrary users on web forms, since you can't easily set the user up with a PGP key or an X.509 certificate.
If you are deploying a web site from a hosted environment, it is possible that the code you control could encrypt the data and then send it. You could, for example, use GPG to encrypt with a public key of your own, and then send the results out in an email message. But that requires code, not just a mailto: url.
Unless you can find a public key encryption library in Javascript.
In short no. Email by default is un-protected. You use encryption programs to protect the information inside, but that requires the end user to be able to decrypt it.
The easiest way would probably be to create an ssl encrypted site where the user can log in and access the information.
You may want to look at http://ecocrypt.com/SecureMessage/
This will allow you to create an encrypted message that can be sent over standard email.
I think they have an API you can use for purchase/license( very low cost...)
But users can encrypt/decrypt in the cloud without having any set up requirements.
This will create a message like:
Encrypted Message Using http://ecocrypt.com/SecureMessage
To read this secure message do the following:
1. go to http://ecocrypt.com/SecureMessage:
2. Copy this ENTIRE message into the encrypted message area:
3. Enter the message pass phrase:
4. Press the Decrypt button:
NOTE: the message pass phrase was sent in a separate message, or the sender assumed you already have it.
NOTE: If you need or lost the pass phrase contact the sender at:test#ecocrypt.com
------------------HEAD--------------------------------
ECOCRYPT:67570:95992fad87a1165c100a0b915f86ce7f:
------------------START--------------------------------
GyuyjmHF68edfoSGM0YqtICXPrA6P69Pf7pXdgZ22g1PjzoANDOVy+0UJ/P0Pb+B09O+IsXqWPus
BO1gsVOA1BnMEE5r68A2fa02nRC9F3anVV8rvZDiZdfu9up2uDWrtsGhlLcHI6iKau4z7dAxq6qV
k7C/o2l3
------------------END--------------------------------
It can be decrypted if the user knows the correct pass phrase.
Same address in the cloud: http://ecocrypt.com/SecureMessage/
The message Decrypted:
Greetings,
This is a test Message.
Sensitive Information Goes Here:
name ss and other sensitive info.
Thanks.
I use Gmail SMTP which uses TLS. I'm not a .NET person but it's very easy to connect to through a Rails app for instance. And it's free!! Of course I think you only get about 200 msgs a month, but you can pay for more
If you have "control" of the receiver side (by this, I mean if the receiver is not a lambda user), I'll go for public/private key encryption with PGP. This article has a fully working example using GnuPG with .NET.
Let me rephrase the information flow to see if I got it right.
a) User U puts information into form at website W,
b) W then sends information to U via eMail.
That makes two communication processes that have to be protected. As you are only asking for protection of b) I assume you are already using TLS/SSL during a).
To protect b) you need some keys for encryption. I see two solutions: either some symmetrical secret that is exchanged during a) or some asymmetric public key that is exchanged during a). The latter one doesn't need any secrecy during a), which is an advantage, but you still need to authenticate that this key is indeed coming from U.
Both types of keys may be transferred during a), you probably just have to insert a new field into your form. In both cases U needs to have the necessary software to decipher any encrypted communication received in b). Having x509-Certificates or PGP-Keys as the two standard encryption algorithms these are probably the best guesses to start with. I am not sure how much is supported by ASP.NET, but even if I assume eMail encryption is not supported directly, some encryption should be supported.
Problem still is, that you will not find a solution that does not assumes some features of U's mailclient (above reading eMails, for some of us encryption is a fairly common feature).