<div dir="ltr"><br>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.<br><br>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.<br><br><div>A solution to this problem is proposed in <br></div><div><br></div><div>"A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers"<br></div><div><br></div><div><a href="https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki">https://github.com/craigphicks/efail-safe-send-to-insec-recv/wiki</a></div><div><br></div><div><br></div>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.<br><br>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.<br><br>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*.<br><div><br></div><div>You can play around with the attackers choice of starting delimiters in this Try jsoup sandbox example<br></div><div><br></div><div><a href="https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI">https://try.jsoup.org/%7E_nyXks5PuAs-zJeek8CVhpuAvtI</a><br></div><div><br></div><div>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.</div><div><br></div><div>More detail is included in the above github document.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>Craig Hicks</div><div><br></div></div>