Re: [openpgp] AEAD Chunk Size

["Neal H. Walfield" <[e-mail]>]

Hi Tobi,

On Sun, 03 Mar 2019 19:36:08 +0100,
Tobias Mueller wrote:
> By fixing a "chunk size" you take away the ability to benefit from AE
> for messages bigger than that size.
> Implementations could easily collect all chunks and only release the
> plaintext once all chunks check out successfully. But that could go
> wrong. And depending on implementations to get things right and clients
> to use those implementations correctly is exactly what enabled Efail to
> become an issue. I think it'd be much nicer if the protocol already
> ensures that my emails do indeed enjoy protection against modification
> rather than me having to rely too much on clients getting it right.

You're afraid of bugs.  So am I.  Dynamically resizing buffers is
error prone.  Even computing AEAD's chunk size is hard:

  #include <stdio.h>

  int chunk_size(int c) {
    return 2 << (c + 6);
  }

  int
  main(int argc, char *argv[]) {
    printf("%d\n", chunk_size(32));
  }

  $ gcc -Wall a.c
  $ ./a.out
  128

(Note that gcc doesn't even produce a warning!)

But, that's not all.  If there is the possibility of failing due to a
lack of buffer space, implementors won't bother.  And they won't
bother for a very good reason: users want to get work done.  If a
security policy prevents them from getting their work done, they will
disable it.  Or, an implementation will ignore it.  And, because it is
only a problem if there is an attack, users will be thankful for the
more "powerful" solution.

The secure implementation must be easy for both developers and users.
And the secure implementation is a small, fixed sized buffer, even if
that means the client may have to worry about truncation.

> Having said that, I understand the desire for fixing a chunk size to
> reduce complexity for implementers.  My desire as a user is to have a
> strong and resilient protocol.

Perhaps you're not a typical user :D.

> Is there another way to do real AE?

Chunked AE is still real AE: it still has ciphertext integrity; it is
just susceptible to truncation attacks.  That's not to say that
truncation attacks are not a serious issue, but I'd rather have
truncation attacks than truncation attacks *and* ciphertext modication
attacks.

:) Neal

P.S.  Consider realloc.  It is only marginally easier to write this
wrong code:

  p = realloc(p, 2 * size);
  if (! p) {
      // Oops, p has been leaked!
      return ENOMEM;
  }

than this code:

  void *temp = realloc(p, 2 * size);
  if (! temp) {
      free(p);
      return ENOMEM;
  }
  p = temp;

but I see lots of instances of the former when reading code.