EFail mitigations for S/MIME

[Andre Heinecke]

Hi,

On Wednesday, May 16, 2018 5:30:47 PM CEST Ángel wrote:
> On 2018-05-16 at 14:09 +0200, Andre Heinecke wrote:
> > Not really. I also don't think that it needs to be encrypted. 
> > 
> > Basically: Alice sends Bob encrypted data and also sends Bob "This is
> > the hash of the plaintext" by signing the plaintext.
> > 
> > Then Bobs client can know "This plaintext matches the hash Alice told
> > me about". -> It has not been manipulated.
> > Even if Eve can manipulate the Hash that Alice sends to Bob she can't
> > create a valid Hash for the original plaintext + her modifications.
> 
> At first sight, it looks enough, since it would require already knowing
> the plaintext. However, it is not. You are providing an oracle that
> allows confirming whether a content is the one suspected by the
> attacker.

For the usual S/MIME mail case I would say that this is mostly mitigated 
because the hash is encrypted in that case. As the only case we would accept 
for mail would be sign then encrypt and would only show the signed parts.

But in general you are right about the problems of an unencrypted hash as I 
have proposed / suggested it and thank you for pointing it out.

I still think that the situation might be improved if we would strongly 
suggest / force users to provide signatures for CMS encrypted files, too. This 
should be done anyway, especially for active content like HTML or a binary.

On the other hand the situation with this is not really changed with EFail. If 
you handle unsigned files you can't trust the file by cryptography alone. And we 
already warn when we handle unsigned content in Kleopatra.

So we might only enforce this for active content in mails for Outlook.

> Suppose we are in the context of a poll, where Alice sent Bob "The
> president should be Charlie". At the end of the vote, Bob publishes the
> encrypted mails, for auditing reasons.
> Eve wants to know for whom did Alice vote, so she -suspecting she voted
> for Charlie-, extracts the encrypted content, adds her own hash for the
> guessed plaintext, and sends it to the victim (she can perform any
> cipher malleability attack by simply adjusting the final hash).
> If the content is decrypted, it means she guessed right. Otherwise, the
> encrypted contents were different, the decryption failed and she will
> try the attack again with another candidate. (She may even be able to
> test several guesses in a single malicious email)
> 
> You need both pieces to be linked. It could be enough to just include in
> the hash computation a "secret IV" that is stored in the encrypted part,
> but it seems fragile, and at that point, I would simply include the hash
> itself.
> 
> 
> (Obviously, if you were really including a cleartext-signed hash of the
> message, Eve wouldn't need to perform an efail attack at all, as she
> could simply test the hash against the list of people running for
> president)

I agree with you and all others here that proper AE would be much much better. 
I'm just thinking about a quick solution to improve the situation for Gpg4win 
users without relying on any support from other clients.


Best Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180517/9720b3a9/attachment-0001.sig>