Resolving "Message integrity" Errors
OpenPGP addon for Mozilla Thunderbird
Brought to you by:
pbrunschwig
Menu
▾
▴
Hi Patrick,
you are quite clear to us users in telling us how we are allowed to use encryption, and that this is the only valid opinion. So I will be as clear to you: your attitude is highly ignorant.
How can you dare or anybody else to decide for me that I should not be able to read my encrypted emails of the last 20 years anymore? What lets you think that these emails are not important anymore to me? They were sent to me and remained in my box because I wanted to preserve them and possibly read them! You prefer that nobody, including me, can read my most important information, than to take the risk (my personal risk, which you cannot know, by the way) that somebody reconstructs my private key (which, as I understand from your comments https://sourceforge.net/p/enigmail/forum/support/thread/03ebee57/#6686/4849/2875/36cb/af38, can only work if sb knows the decrypted content of some mails, that means, when I enter my password and they have access to my private key anyways, or on the sender's side, where neither me nor Enigmail has control over anyways)?
I am sorry for being upset, actually I was quite relaxed before starting to investigate the issue. But imagine that some hacker, or ransom virus, breaks into your computer and deletes your emails, how would you evaluate this situation? You talk about holding all user hostage because of backwards compatibility. With this change in Enigmail, you are actually taking most of your users hostage whenever they still want access to their old emails. You say that people consider S/MIME broken. I would add now that actually Enigmail has also got broken, but not by design, but by their designers.
I have been propagating encryption for the last 20 years, particularly PGP. I was very disappointed in the beginning by the "official" recommendations to use Signal, Whatsapp etc. and somehow relieved by your reaction regarding PGP and Enigmail. But I will have to re-consider my position. Currently, I would recommend people to install an old version of Enigmail and ask everybody to not use email encryption anymore with myself, but the mentioned apps, as sorry as I am.
Regards
And I will be as clear as possible to you: we will not hold today's
users hostage to your specific needs.
There is nothing preventing you from storing your emails and decrypting
them from the command line. You can invoke GnuPG and pass
"--no-mdc-warning" and everything will work fine. The only thing we are
saying is that you can no longer use Enigmail to do this, because we
choose to no longer support using old and broken crypto with Enigmail.
You are able to. We've just decided we're no longer interested in
having Enigmail support your use case. And so long as we're the people
writing the code, writing the documentation, developing out the
standard, and so on, not only do we get to decide what kind of use cases
we will support, but we have to decide what kind of use cases we will
support.
We have decided we will, in the interests of protecting the security of
our entire userbase, not continue supporting your use case.
We're sure they are and we hope you have good luck finding a tool that
reads them. GnuPG will do the job wonderfully.
I understand you're angry by this change, but we're not going to revert
our policy. We're glad Enigmail was a good tool for you for so many
years, and wish you luck in the future.
Hi,
Thanks for being so clear, Patrick.
If someone finds/founds another project for providing access to my old mails within my MUA - please drop me a note.
Maybe thats not too much as a fork of enigmail?!
BR - Henning
You write 'The threat behind "no MDC" is that an attacker knowing the decrypted content of a set of messages (any modified variants thereof) can derive parts of your secret key from it.'
This cannot be true unless the used schemes are broken anyways, right? We require IND-CPA or IND-CCA security for encryption and EUF-CMA security for signatures.
An attacker can always use the public key to get as many valid plaintext-ciphertext as it wants. If that is enough to find out (parts of) the secret key the scheme is broken.
gpg can decrypt and then check the signature in place of the MDC as far as I understand. Should the signature be invalid it can still refuse to hand out the decryption in standard scenarios, ie. before Efail can use the decryption.
The point here is different. This is not about signing, but about encryption. Encryption happens after signing, i.e. it's "outside". A broken signature does not prevent the message from being decrypted/displayed, it's just a message with an invalid signature.
If an attacker modifies an encrypted message that does not have MDC protection, you won't notice the modification. The attacker may even remove the signature without you being able to notice it. If you decrypt a modified message, you might find out that the signature is broken, or that a part of the message is garbled, but you cannot detect the fact that someone modified the message. Let's assume you reply to such a modified message, then you might let the attacker know at which point the message was modified and how the modification was decrypted. And this may reveal information about your secret key (at least in theory).
That's not my point.
MDC gives some integrity protection for the cipher text. Agreed.
Without that an attacker might modify the cipher text. Proceed as follows:
Let gpg decrypt.
If there is no signature, return a warning/error but NO plain text.
Otherwise check the signature.
If the check is bad, something went wrong, maybe an attack, so a warning/error but NO plain text is returned (by default).
If the check is ok, you have integrity protection and the plain text can be safely returned.
This way you also have the desired integrity protection, don't you?
What you explain does not break my proposal. Any attacker modification would either destroy or remove the signature (if any) [or break at least one of the schemes].
This way all the "old" but signed messages could still be displayed safely.
Am I right?
Only those old messages that were merely encrypted and had no signature nor MDC would be problematic; yet, using encryption w/o authentication was already a bad idea ages ago.
Last edit: Michael Nüsken 2018-06-19
No.
If a good signature from a validated key is present, you can be sure the
message wasn't tampered with in transit. But if any of those fail to
hold true, it doesn't mean the message is bad or unauthentic: it just
means there's no assurance of integrity. There's no difference between
an unsigned message and a message with a bad signature, or a good
signature from an unvalidated key: all of them mean "there is no promise
of message integrity".
But the message could still be good!
An MDC is an anti-signature. It doesn't make any promises a message
comes from an authentic person. It just promises the message hasn't
been tampered with -- which is a much different promise than the
signature gives. A bad signature doesn't tell you the message is bad,
just that the message isn't guaranteed to be good. A bad MDC tells you
the message is bad.
An MDC, by itself, is an inadequate solution because you can't use it to
prove a message is authentic.
A signature, by itself, is an inadequate solution because you can't use
its absence/brokenness to prove a message is inauthentic.
Using them both together lets you make some extremely strong
pronouncements about the integrity of the message.
"But the message could still be good!" I was not talking about the cases with wrong or missing signatures. Yes, sure, they can be fine.
All your explanations about the MDC are fine but off-topic.
"A bad MDC tells you the message is bad.": I cannot see how anything missing or invalid can prove that the message is bad. The MDC can at best prove that the message hasn't been modified since the point in time when the MDC was added.
Dear Rob,
I also believe Michael has a point: If there is a valid signature from a validated key, then the message is protected even if there is no MDC present.
I by default encrypt-to-self, and also by default sign outgoing messages. Still, I cannot open old messages in my sent box if just one of the receipients did not declare MDC support, because then no MDC is present at that mail and I get a message Integrity error. But Message integity is given due to the trustworthy signature by my own key.
As an additional showstopper, I use PGP/MIME by default. For such messages, decrypting the ciphertext, then reimporting the multi-part message into the mail client sounds like almost impossible. I will have to decrypt, then mime-split, then recombine the message. Or simply declare a lot of mail sent/received within the last 15 years "lost".
But I agree you need a good signature from a validates key for this. A good signature from an unvalidated key is not enough. I am not sure if TOFU might be a bit of a problem here. But, I have validated and signed the keys from most of my correspondents.