ietf-openpgp
[Top] [All Lists]

Re: [openpgp] AEAD Chunk Size

2019-04-12 08:46:27
On Fri, 12 Apr 2019 15:36:58 +0200,
Derek Atkins wrote:
Marcus Brinkmann 
<marcus.brinkmann=40ruhr-uni-bochum(_dot_)de(_at_)dmarc(_dot_)ietf(_dot_)org>
writes:

The main question here is: What should a conforming application look like?

The current behaviour of GnuPG is that it will process internally (e.g.,
through the decompression and signature verification layer) and output
externally unauthenticated plaintext.  If an AEAD chunk is modified by
an attacker, GnuPG will detect the modification and cancel the
operation, but only at the end of each chunk.  Due to the asynchronous
buffer management in GnuPG, quite often some part of the modified chunk
has then already been processed and output, depending on the particular
state of the buffers, the buffer size and the chunk size.  This
behaviour increases the surface for chosen ciphertext attacks and
possibly adaptive chosen plaintext attacks (if an oracle is exposed).

In my mind, this sounds like the implementation is broken.  If it
releases AEAD plaintext before the end of the AEAD chunk then it is
non-conforming and should be considered broken.

I fully agree with you.

Given this position, it seems to me that all implementations will
necessarily fail on very large chunks (e.g., 4 exabytes).  So, why
even allow them [1]?  It seems to me that these permissible options
just create a temptation to create broken implementations.

Thanks,

:) Neal

  [1] https://mailarchive.ietf.org/arch/msg/openpgp/n1-e2shFQMqLphGY2VUvxdr9T40

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp