A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers

[Craig P Hicks]

At some finite date in the (hopefully) near future, most email client over
GnuPG users will have an EFAIL-reading safe system setup, if they don't
already.  MDC will be strictly enforced.

However, the situation for a secret message sending is not so good. There
is no way to guarantee that the reader/receiver has updated their software
and/or settings. Statistically speaking security updates are not enforced
uniformly; there are always laggards. Therefore, without adequate
additional precautions, there will always exist the possibility of a secret
message writer/sender's message being read by an EFAIL attacker.

A solution to this problem is proposed in

"A Solution for Sending Messages Safely from EFAIL-safe Senders to
EFAIL-unsafe Receivers"

https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki


Because each block is vulnerable, the solution works by individually
protecting each block against being wholly included as part of an HTML
attribute.  It is possible because the attacker is restricted to dividing
the message along encrypted block boundaries.

The solution is very simple.  The plaintext to be encrypted in a single
block is divided into two parts.  This first part is obfuscating string
*o*, and the second part is message *m*.  The choice of *o* prevents *m*
from being included in the attackers attribute value.

Specifically, the obfuscating string *o* must have a least the three
characters single quote ('), double quote ("), and space ( ).  That's
enough for force the closure of the HTML attribute and protect the message
*m*.

You can play around with the attackers choice of starting delimiters in
this Try jsoup sandbox example

https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI

When decrypted by the user in its raw form the total message will be human
readable but a little ugly because it contains the obfuscation string *o*,
but it will be safe from EFAIL.

More detail is included in the above github document.

Because alignment of the obfuscation part with the encryption block
boundary is critical, the implementation should be done in the base module,
e.g. GnuPG, rather than an email client.  Of course it is not a GnuPG
fault, it just happens that's the obvious safe place for this proposed
solution.

I've put in a request for feature to gnjpg dev, to get some feedback.  I'm
hoping there may be readers here willing to give critical feedback.
Depending on the feedback I would try to move it forward.

Craig Hicks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180522/3c3db5ac/attachment.html>