It's a very simple proposal. The plaintext of every encrypted block is prefaced by an obfuscation string part which prevents the message string part vcoming after it from being part of the EFAIL attribute. The EFAIL can attack each block seperately, but it can't divide and conquer a block itself.
The obfuscation string needs to contain a double quote ("), a single quote ('), and a space ( ). You can immediately see how it works by looking at this HTML sandbox: try.jsoup.org/%7E_nyXks5PuAs-zJeek...
where you can play around with the choices the EFAIL attacker has and the opportunities to defend against it.
It depicts a typical 16 bytes string to be encoded in a single block, but it is safely prefaced by an obfuscation string.
Did I mention it has to be uncompressed? Because compression ruins the boundary alignment. And of course for any reader who doesn't have software to remove the obfuscation parts, the mail is ugly, although still readable.
More technical details are in the document.
I have tried to offer a whole system cost/benefit analysis at the end.
If it were to be implemented it would have to be implemented close to the encryption/decryption, e.g. inside the GnuPG module. That is because aligning the obfuscation string with the encryption block boundary requires close coordination. Too easy to make a mistake otherwise.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have posted a document:
A Solution for Sending Messages Safely from EFAIL-safe Senders to EFAIL-unsafe Receivers
It's a very simple proposal. The plaintext of every encrypted block is prefaced by an obfuscation string part which prevents the message string part vcoming after it from being part of the EFAIL attribute. The EFAIL can attack each block seperately, but it can't divide and conquer a block itself.
The obfuscation string needs to contain a double quote ("), a single quote ('), and a space ( ). You can immediately see how it works by looking at this HTML sandbox:
try.jsoup.org/%7E_nyXks5PuAs-zJeek...
where you can play around with the choices the EFAIL attacker has and the opportunities to defend against it.
It depicts a typical 16 bytes string to be encoded in a single block, but it is safely prefaced by an obfuscation string.
Did I mention it has to be uncompressed? Because compression ruins the boundary alignment. And of course for any reader who doesn't have software to remove the obfuscation parts, the mail is ugly, although still readable.
More technical details are in the document.
I have tried to offer a whole system cost/benefit analysis at the end.
If it were to be implemented it would have to be implemented close to the encryption/decryption, e.g. inside the GnuPG module. That is because aligning the obfuscation string with the encryption block boundary requires close coordination. Too easy to make a mistake otherwise.