[CleanNet Spam:] Re: "decryption forced to fail" due to missing signature?
Neal H. Walfield
neal at walfield.org
Wed Jan 24 10:49:21 CET 2018
At Wed, 24 Jan 2018 08:47:28 +0100,
Werner Koch wrote:
> On Tue, 23 Jan 2018 16:28, Alexander.Strobel at giepa.de said:
> > But this does not solve the inconsistency in "showing an error and still
> > return decrypted data" I see when MDC is missing. Maybe someone can
> As a Unix tool gpg streams the data and does not buffer it. Thus at
> the time it detects a mad MDC it is too late to remove the already
> written data.
Streaming doesn't imply no buffering. It means that the size of the
buffer is O(1) even though the size of the stream is O(n). Even a 1
byte buffer is a buffer.
Given that some minimal amount of buffering is going on, it is
possible to not output the last bit of data if the MDC doesn't match.
Since most emails are small (gmail appears to enforce a maximum
message size of 25 MB, for instance), one could set the buffer to 25
MB to make sure nearly all emails have their MDC checked.
The question is: is a 25 MB buffer too large? Well, I don't think you
can buy a desktop machine or phone with less than a few GB of ram
today. So, 25 MB is probably safe. For servers with high-levels of
concurrency, and small embedded devices, it might be reasonable to
provide an option to control the amount of buffering. But, even here
1 MB will probably be acceptable, which, if managed carefully (e.g.,
only flush 50% of the buffer when it is full) should hopefully corrupt
the output enough that it becomes unusable even if the MDC failure is
FWIW, this is the approach that I'm taking in Sequoia.
More information about the Gnupg-devel