AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] Im Auftrag von
> 
> On 14/05/18 12:25, Robert J. Hansen wrote:
> > The problem is that gpg doesn't say anything. I would expect a
> > DECRYPTION_FAILED message here:
> 
> So perhaps the solution is to throw a big warning and prompt when an
> integrity check failure is thrown by gnupg? That would mitigate the
> current issue, but allow for reading pre-MDC emails as per Werner's
> earlier link.
> 
> The problem here is that an integrity failure is a serious error when it
> occurs in a context where oracle behaviour is possible (such as email),
> but it's much less serious when used outside that context. Just because
> gnupg says it's only a warning-level offence doesn't mean enigmail
> should agree...

In my opinion, the problem is related to the general gnupg interface design. An optional error or warning is always somehow problematic in interfaces:

1) you have to read and understand the complete documentation to know of any message that may occur

2) if it is not here, you simply do not know, if everything is right, if you just missed the message or an attacker managed to "suppress" it somehow. Makes it easier on the attacker - like here

In my opinion, gnupg would do itself a favour by avoiding optional messages - without any other reference to it. With such a protocol I would expect gnupg to end somehow like ...

[END_STATUS]: Messages: 3, Valid MDCs 2, Signed Messages 2, ...., Warnings: 1, Errors: 0 ... (put here everything you deem important and document it)

This would also prevent many other programming errors: e.g. if gpg claims to have processed 2 signed messages, a client has to verify, that it also received two "GOOD_SIG" messages. If just any of the numbers do not match, any good mail client should bail out immediately, e.g. if warn=1 but the client did not understand the warning.

LG R

PS: A end message as single line sorted JSON dictionary might make parsing less error prone and increase the number of developers really parsing and using them.