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.
Related
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.
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.
I have a PGP key created, submitted to the pgp.mit.edu and then signed by a friend to join his path(network).
Now I want to start and send an e-mail signed (not encrypted) using the Thunderbird e-mail client, but there it is saying to upload a certificate file which extension is like *.p12, *.pfx, *.crt etc.
I created my key using the Kleopatra software, how can I create this certificate, if not possible, how can I sign my e-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
I encountered a strange behaviour using BouncyCastle.
A email without any attachment is encrypted in BouncyCastle and send through JavaMail.
Looking at it in Outlook, an attachment is shown. In fact there is no given opening the encrypted mail.
Encrypting the email just with Outlook, there is no such phantom-attachment.
Any idea why BC is doing this?
Is there any way to avoid it?
Thank you very much!
Nick