Re: Avoiding double writes

John Goerzen
2021-11-02T15:27:50Z

On Tue, Nov 02 2021, Sergey Matveev wrote:

> Well, actually currently I do not see the strong need of the
> size too.
> Of course it is nice to be able to quickly (just decipher single
> block
> of data) determine real payload's size, but for years no
> code/command
> did this, except for nncp-pkt for debugging.

Yes, and for giving user output, the size of the encrypted packet
could be used too.

> However with MTH it is possible (if I am not wrong) to write
> everything
> encrypted except for the first block(s), then returning back and
> preappending those first blocks with the known size. I am not
> sure, but
> that will require changing of much NNCP internal code, aimed for
> streaming exclusively. But that won't require changing of the
> existing
> encrypted format.

But I don't think even this is needed, since as we're saying, we
don't have a strong need for the size.

> So format change is definitely needed now :-). It is
> vulnerability, but
> of course not the crucial and hardly seriously exploitable,
> leading only
> to possible real payload's size leak. Padding length has to be
> authenticated.

Interestingly, AFAIK, OpenPGP has no provision for padding and its
packet headers are unencrypted, so agreed that it isn't a big
deal.

> But as we are going to change the format anyway, I think that it
> is safe
> to get rid of SIZE field completely, adding some "signalling"
> metainformation to the blocks, not forgetting about padding
> authentication. And that won't affect much code I presume.

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.

>>But I'm also confused about the signature - since that comes
>>before the
>>encrypted blocks, isn't that also a problem?
>
> Signature is made over the encrypted packet's header only. It
> comes
> after the header itself, so do not see any problems :-)

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?

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?

Thanks,

- John