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

[Fiedler Roman]

> Von: Werner Koch [mailto:wk at gnupg.org]
>
> On Wed, 16 May 2018 16:24, Roman.Fiedler at ait.ac.at said:
>
> > In my opinion it is hard to find such a "one size fits all"
> > solution. Like Werner's example: disabling decryption streaming
>
> The goal of the MDC is to assure that the message has been received
> exactly as the sender set it.  Thus there is just a binary decision:
> Okay or Fail.  Everything is like you have been dropped at boot time
> into manual fsck mode - you can do something about it or you just
> irginore things and restore the partition.

How could that work together with the memory based "wipe" approach, you envisioned in your message https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last paragraph?

If I understand your approach correctly, it will imply that at least one do-not-apply-one-size-fits-all switch has to be present, thus contradicting one of your statements. Or did I get something wrong in my argument? The decision output (fail/ok) in the end might be binary for both use-cases but the internal logic (process model) for validation/output will be different.

> > streaming of backups (decryption&output before final validation). So
> > you need something on the interface to support that non-standard
> > behavior, deviate from the default.
>
> It is already there.  If you use "--output FILE" the file is either
> created or not.  Your choice.

Would that imply, that using e.g. "--output /proc/self/3" would implicitly change the security behavior of gpg, e.g. by switching from "output before validation" model to "validation before output" model (again compare your message, cited above)? Implicit feedback from selected output mode on security related MDC-check behavior would seem dangerous to me. Somehow rings an alarm bell, if that should be the proposed solution.

LG Roman