AW: AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: Werner Koch [mailto:wk at gnupg.org]
>
> On Tue, 15 May 2018 11:44, Roman.Fiedler at ait.ac.at said:
>
> > The status line format should be designed to support those variants to
> > allow a "logical consistency check" of the communication with GnuPG
>
> There is a
>
> DECRYPTION_FAILED
>
> and that is all what it takes.

But this is only a single status code for a very complex decryption/validation process (considering cipher methods, signature methods, local time, trust DBs, signatures, number of messages, ...). When relying on that single code, gpg would need configuration parameters to configure each step of the whole decryption/validation process in a very fine-grained way, so that gpg will know in the end, if it should issue the FAILED or not. I am not sure, if gpg could support implementation/testing/life-cycle-efforts to establish all those parameters and different process models for most of the decryption processes gpg users envision to use gpg for.

> If the integrity check fails there
> should be no easy way to circumvent this. RFC-5083 states this cleary:
>
>    The recipient MUST verify the integrity of the received content
>    before releasing any information, especially the plaintext of the
>    content.  If the integrity verification fails, the receiver MUST
>    destroy all of the plaintext of the content.
>
> Unfortunately this can't be done by tools prepared to process huge
> amounts of data.  And in contrast to the Efail claims this is an
> important feature. How would you else do your ZFS backups without
> having a way to stream the data to the backup system.

This is just the example of two different, complex decryption/validation processes, that should be supported both. As the definition of the "process" also has implications, what a valid "integrity check" is (see also the discussion about historic messages), I believe, that this is hard to be done by breaking it down to a single 0/1 decision for gpg (which might not know the constraints of the current process in detail). Otherwise a "--allow-non-rfc-5083-streaming-mode" flag should already exist to tell gpg more about the decryption process constraints (to distinguish between the two different process models, that should be implemented already, just for your RFC-citation from above).

> ...

LG Roman