Mailpile
Mailpile copied to clipboard
mailpile
When Conversation Encryption State Changes, Mailpile Should Remove Quoted Text
Problem:
When I am quoting text while replying to or forwarding an email and I change the encryption state of the email I'm writing (to one different than when the conversation began), I am leaking key information. Mailpile does not, but should prevent me from doing so.
Examples
Examples for each use-case follow.
Reply
When I quote text in an unencrypted reply to an encrypted message, I am sending the plain-text of the encrypted message. This action leaks the original sender's key information. For example, if Bob sends me an encrypted message and I reply with plain text while quoting the email, I have just leaked some amount of Bob's key.
Alternatively, when I quote text in an encrypted reply to an unencrypted message, I am leaking my own key: I am providing an encrypted form of a known plain text to someone else's public key.
Forward
When I quote text in an unencrypted forward of an encrypted message, I am sending the plain-text of the encrypted message. This action leaks the original sender's key information. For example, if Bob sends me an encrypted message and I forward with plain text while quoting the email, I have just leaked some amount of Bob's key.
Alternatively, when I quote text in an encrypted forward to an unencrypted message, I am leaking my own key: I am providing an encrypted form of a known plain text to someone else's public key.
Impact:
Mailpile allows me to leak my or another person's secret key data. This exposes my private key rendering it useless for it's intended purpose (to remain private).
Solution:
Mailpile should not allow users to quote text while changing the state of encryption on a message. Mailpile could do this through either:
- Erasing the quoted text when replying (possibly with a warning before doing so), or
- Preventing the user from changing the encryption status of the message.
Of particular concern are usecases where users are forwarding messages to users who don't have secret keys, where the original author did. In those cases, Mailpile might consider it reasonable to automatically decrypt the message behind the scenes, but that is unacceptable, as it again leaks the user's key.
Metadata
Please tag this bug with the "privacy/security" tag, I am unable to do so in the GitHub app.
Thank you for your time in reading this bug report, Nick
Hi!
While I agree that this needs to be fixed so as not to expose the secret of the message in your use case, you are wrong in saying that you can leak another person's secret key data. If this were true, then you could pretty easily discover my secret key by choosing a plaintext and encrypting it to me, and then analysing the plaintext and the ciphertext together. Thankfully, you cannot do that.
PGP is not vulnerable to known plaintext attacks. PGP combines an asymmetric algorithm (typically RSA) with a symmetric algorithm (typically AES) in some block cipher mode. If we assume that the cipher (AES) is not vulnerable, which it isn't, and the block cipher mode doesn't expose the symmetric key probabilistically (it isn't using ECB, which it doesn't), then discovering a future encrypted message from a known partial plaintext is still virtually impossible (I'd like to say "impractical", but that might lead people to think that I mean "could be done in practice", which I don't).
But even if partially known plaintext were to expose the AES key used to encrypt that particular message, which it won't, it would give you absolutely no knowledge of the RSA keys which you didn't already have. In fact, it would probably not even give you enough information to be able to uniquely reconstruct the public key in any reasonable amount of time.
Do not worry. Mailpile is at zero risk of breaking RSA in any fundamental way. :-)
Hi Smári, thank you for the thoughtful and detailed response.
I was unsure about the leaking-someone-else's-key part, I clearly should've been more circumspect in my write up. Though, it helps that I seem to have gotten most of the problem wrong. :)
You've mentioned several algorithms in different cipher modes and described combinations which aren't vulnerable. That leads me to wonder: is it possible to create a PGP key in a way that would be vulnerable to a known-plaintext attack? What would that key look like? Can Mailpile warn users when it encounters such a key?
Actually, outside of the secret-message leaking, that's probably a minor and mostly academic worry. Thank you for taking the issue of leaking the secret message seriously, despite the rest of the report.
Thanks again, Nick
P.S.: Known-plaintext attacks on PGP are something bandied about fairly frequently when folks talk about attacks on PGP, it might be good to refer folks here in the future.
@NickDaly
Mailpile allows me to leak my or another person's secret key data. This exposes my private key rendering it useless for it's intended purpose (to remain private).
Chosen wording is not totally clear to me.
I think you meant the hex ID of a PGP key of which you wouldn't want to divulge to other persons than the recipient the existence in association with the e-mail address you sent from, not the secret key itself (the hex ID or the whole public key).
If you meant that you ran into some gnupg+Mailpile loophole leaking the secret key itself, meaning the secret part of your PGP key, and not something the existence of which you want to maintain a secret (even the public PGP key because it would reveal that you do have a PGP key associated with that e-mail address), then what follows is not an answer (but I suppose it's not the case, because you also mention "another person's secret key data").
If you didn't mean that, this is a possible answer:
Mailpile should not allow users to quote text while changing the state of encryption on a message. Mailpile could do this through either:
1. Erasing the quoted text when replying (possibly with a warning before doing so), or 2. Preventing the user from changing the encryption status of the message.
Understandable concern.
- Copy&paste would still be allowed I guess... how would you prevent it anyway? Or a screenshot being taken?
- A journalist might want to quote "anonymous sources...".
- You are always trusting somehow the person to whom you send anything, or otherwise limiting what you send to that person or modifying the form in which you send, e.g. allusions and questions instead of plain statements that you might want to be able to deny later.
- Keys are not necessarily secret forever, either (even airgapped ones, see "Kleptography") and encryption schemes are not necessarily going to remain uncompromised forever. You can also send sensitive material from an account not revealing your identity.
- And you can't assume that the recipient will be using Mailpile anyway, and not another client or a modded Mailpile.
(Why am I answering an issue created 6 years ago and closed 3 years ago? Well, because I thought it might affect future choices.)
