*** John Goerzen [2021-11-02 10:26]:
>Yes, and for giving user output, the size of the encrypted packet could be
>used too.

Agreed.

>Yes, exactly.  This metadata could be as simple as a u32 indicating how much
>of the following block is actual data.  Any u32 value beneath 128K
>(including zero) would indicate we've reached EOF of the original data and
>everything past that should be authenticated but discarded, I think.

I assume something like that, indeed. Plus included size of the
padding/junk, to be sure that we received all of it, packet is not
stripped. We have got holidays soon, so I hope will implement that.

>Ahh, that makes sense.  I'm not all up on my crypto algorithms, but if I
>understand correctly, each encrypted block is authenticated with the BLAKE3
>hash of that block plus the unsigned portion of the header?  And since that
>portion of the header contains the public part of the session key, that
>prevents data injection attacks, right?

Mostly you are right. Each (128KiB and SIZE) block uses BLAKE3 hash of
the unsigned part of the header as an associated data, used as an
additional input to AEAD-encryption of the block. So each block is
"tied" to the context it is used with: exactly that sender, recipient
and ephemeral public key. And each block uses implicit increasing nonce
counter, so blocks can not be reordered, thrown away or injected. Blocks
can not be taken from another "context" (another encrypted packet),
because of associated data.

>So it would be possible with this streaming approach to still determine with
>certainty if we have received the entire file's data, and the correct data,
>by processing the hash and header for each block, right?

Do not understand you clear :-(. Yes, we can be sure if we have received
the whole data or not, by looking if we reached "final" payload block,
containing also the size of the padding.

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF