Re: [openpgp] AEAD encrypted data packet with EAX

["brian m. carlson" <[e-mail]>]

On Mon, Jul 03, 2017 at 06:41:11PM +0200, Werner Koch wrote:
> On Mon,  3 Jul 2017 18:00, [e-mail] said:
> 
> > Were there opinions on this proposal?  Do people like it, dislike it,
> 
> I have an opinion on your proposal but wanted to give others time to
> reply first ;-).  I have had too many other open tasks this year so that
> my editorial work was too much delayed, I am sorry for this.
> 
> I have two points, briefly:
> 
> 1. The prior discussion showed that it will be hard to find a common
>    conclusion on what algorithm to use.  Thus instead of having one
>    fixed algorithm, I will propose a modification to make the new packet
>    format extensible.  I know that this had a lot of drawbacks and
>    having only one algorithm would be far better than a bunch of
>    algorithms which we may all need to implement.  But the advantage of
>    allow other algorithms will give the implementers more options to
>    to show in practice the advantages of different algorithms.

Yes, I tend to agree.  Did you feel the existing extensibility mechanism
in my proposal (cipher algo, AEAD algo, chunk size) was insufficient or
did you have something else in mind?

> 2. We really should have a way to early detect a corrupt message - not
>    necessary an attack but for example a bit flip somewhere on the
>    channel.  Inserting a running checksum (say, every 1GiB) would solve
>    this.  Obviously this depends on the algorithms, so that the existing
>    cipher state can be used for such a checksum.  A hackish way to that
>    could be to take the internal state of the algorithm, hash it and
>    insert it into the stream.  A cleaner solution would require several
>    concatenated cipher streams.

I think my proposal actually implements that.  Since my chunk proposal
contains the chunk index (basically, an incrementing counter), as long
as we have the key, we can immediately tell if any chunk is corrupt
simply by knowing the chunk size and authentication tag length.  That
allows random-access to data if, for example, you know that all of your
data is uncompressed tar archives.

If we want something simpler in addition, we could reuse the CRC24 as
most implementations will require it for the ASCII armor format.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204