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.
Related
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?
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).
I've a problem with dkik.
I send message signed by dkim but my mail server doesn't support this feature.
So I've generate a pair of keys (private and public) and I've configured the TXT record with the public key.
The problem is that I haven't access to the mail server.
Can I sign the message manually with my client mail or in other way?
Thanks!
Here's a thread that includes some options for client-side DKIM signing - Setting up DomainKeys/DKIM in a PHP-based SMTP client .
That said, most mail servers support DKIM out of the box at this point - you may want to switch to one that does.
Alice wants to talk to Bob.
Bob validates Alice is Alice by sending Alice a nonce.
Alice encrypts the nonce with a key.
Ben also knows what this key is.
Ben cannot remember asking Alice for communication due to the fact that he is operating on a stateless server.
To get around this Alice send Ben his first communication request by sending the original nonce along with the encrypted nonce.
Would I be right in saying this is insecure because if this message containing the original nonce and the encrypted nonce were to be intercepted by a hacker - the two could be reverse engineering and the key 'K' could be obtained?
thanks
I initially wanted to say "don't give the raw string and the encrypted string", but that's pretty much the same as posting the raw data along with the HMAC-hash of the data + secret key at the end. If you're confident that your encryption algorithm is good and you are using a secret key then I don't see how this could be an issue.
However, the entire point of a nonce is to be used ONCE. Alice sends Bob a request with a nonce, and Bob knows that if he gets a request from Alice with that same nonce, ignore it, because it likely came from an attacker and not Alice herself. So you shouldn't be doing this in the first place.
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.