4 ms·

Encryption is not the be-all and end-all of security. Here is a good example: your boss sends you a signed, encrypted message that just says, "You're fired!"

Encryption is not the be-all and end-all of security. Here is a good example: your boss sends you a signed, encrypted message that just says, "You're fired!" You send that signed message to the secretary you have a grudge against, encrypted using her public key instead of yours. Now the secretary thinks she is fired too (potentially leading to mayhem within the company). This discusses the issue in depth: http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html PGP and S/MIME do not encrypt the subject line of emails; this is an easy way to leak information. You also do not get encryption of References/In-Reply-To headers, and various other headers that can leak information.

miloshadzic 14y ago
You're right of course but I think a straightforward way to sign, encrypt and decrypt your email would be a big step forward.
- dmix 14y ago
  Plus (nearly) all security has trade-offs. The trade offs dont necessarily trump the added benefits of the security.
illicium 14y ago
Sounds like a simple solution would to duplicate the headers in the body and encrypt them along with the message. That way, even if you resend that email, the encrypted To: field would make it obvious that it was meant only for you.
mike-cardwell 14y ago
In PGP and S/MIME, the ciphertext is signed. You don't encrypt a signed message, you sign an encrypted message. You can't take a signed message that was encrypted with your public key, decrypt it, re-encrypt it with somebody elses public key, and expect it to still appear signed by the original sender when the new recipient decrypts it. [edit] There are of course serious problems with the lack of header signing/encryption and replay attacks though I agree. Hence why I add a small note at the end of all of the pgp signed comments on my blog: "This signed text was written for https://grepular.com/ https://grepular.com/ only"
koenigdavidmj 14y ago
Don't such systems generally encrypt first and then sign the encrypted text, specifically to avoid this? Your points about subject lines and other assorted headers are correct.
- betterunix 14y ago
  The link I provided discusses this as well; not only are there other attacks, but those other attacks are potentially more severe. A man-in-the-middle attacker can claim credit for a message by substituting their own signature for the sender's. A naive encrypt-then-sign system will also lack non-repudiation in some cases (e.g. when using RSA signatures and encryption), and will only provide non-repudiation on the ciphertext itself (not the plaintext; this may or may not be what you want).

miloshadzic 14y ago

You're right of course but I think a straightforward way to sign, encrypt and decrypt your email would be a big step forward.

dmix 14y ago
Plus (nearly) all security has trade-offs. The trade offs dont necessarily trump the added benefits of the security.

illicium 14y ago

Sounds like a simple solution would to duplicate the headers in the body and encrypt them along with the message. That way, even if you resend that email, the encrypted To: field would make it obvious that it was meant only for you.

mike-cardwell 14y ago

In PGP and S/MIME, the ciphertext is signed. You don't encrypt a signed message, you sign an encrypted message. You can't take a signed message that was encrypted with your public key, decrypt it, re-encrypt it with somebody elses public key, and expect it to still appear signed by the original sender when the new recipient decrypts it. [edit] There are of course serious problems with the lack of header signing/encryption and replay attacks though I agree. Hence why I add a small note at the end of all of the pgp signed comments on my blog: "This signed text was written for https://grepular.com/ https://grepular.com/ only"

koenigdavidmj 14y ago

Don't such systems generally encrypt first and then sign the encrypted text, specifically to avoid this? Your points about subject lines and other assorted headers are correct.

betterunix 14y ago
The link I provided discusses this as well; not only are there other attacks, but those other attacks are potentially more severe. A man-in-the-middle attacker can claim credit for a message by substituting their own signature for the sender's. A naive encrypt-then-sign system will also lack non-repudiation in some cases (e.g. when using RSA signatures and encryption), and will only provide non-repudiation on the ciphertext itself (not the plaintext; this may or may not be what you want).