get pgp privatekey when email content is known - email

Is ist possible to find out the private key if the actual content of the previously encrypted sent mail leaks for example because the recipient answers unencrypted and with a quote?

You should have posted this question at the crypto site. Then you would get more answers and deep explanations.
No, recovering of the private key it is not possible. Even if the unencrypted text is known for millions of encrypted messages, it is not possible to recover the private key.

Related

What happens when an old email is forwarded but the original public DKIM key that was used to check the signature has changed in the DNS settings?

What will happen on the receiving email server when it gets the forwarded email? I assume it will want to check the signature but it will think the signature is invalid. In what folder will the email land, in the inbox or in the spam folder?
I think I forgot the fact that there are two kinds of forwarding:
The first one is the automatic forwarding. This happens ideally pretty quickly. So before changing the DKIM public key we should wait some time or some days to allow the already signed messages to reach their destination.
The second one is the manual forwarding. In this case the forwarded message will be signed again with a completely new signature, with the forwarder's private key. It does not matter if the DKIM public key of the original sender has changed.

S/MIME Mail - signed or not signed - what's the standard procedure for sending to a known recipient

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).

GnuPG: Plugin for Outlook that allows searching through encrypted mails

I have tested gpg4win as a plugin for Outlook. But when I use that I cannot use Outlook to search for body text in the email.
I imagine it is due to the email being encrypted and that Outlook searches through the encrypted email and not the decrypted email.
My threat model is to protect the email transfer. As soon as the email hits our mailserver we consider it safe to store decrypted. So I imagine a solution would be for gpg4win to decrypt the email using my passphrase and then store the decrypted version back on the system and my local cache, which can then be searched as an ordinary email.
Is there a way I can search through encrypted emails using Outlook?
Ole,
you should give gp4o a try. gpg4o
If you want you can save the mail after decryption, so it can be processed by the indexer. Additionally it is the easiest PGP plugin I have discovered
Best regards
Karl

Email Attachment Encryption - RSA or AES?

I'm developing an email server from scratch for a custom project. I understand RSA and AES but where I am lost is in handling attachments. I want to send Alice a signed message and I also want to send her an encrypted file attachment. How are attachments typically handled in this scenario?
Thanks in advance!
Attachments are big files and asymmetric encryption is really slow (i.e. RSA) so it is best to generate an AES key and encrypt it with the RSA public key and then encrypt the attachment with a lot faster AES. Then send both the encrypted key & attachment to the recipient. As only she got the private key, only she can decrypt the AES key thus can decrypt the attachment.

Best practice to send secure information over e-mail? [closed]

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).