Greetings!

*** John Goerzen [2021-11-01 19:11]:
>So, from a glance at the code, this size is primarily used for:
>- differentiating encrypted data from padding
>- display output

Exactly.

>Is it even really necessary to store a size?  I was thinking of
>something along these lines also, with the signaling byte (or, perhaps
>more accurately, a blocksize indicator).

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.

So I agreed with you that signalling will be more than enough, allowing
"streaming" creation of encrypted packets.

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! When I woke up, I realized that junk (padding) is not authenticated
anyhow now! If packet has two bytes of padding, then you can process it,
then strip off the last byte, because of MTH-hash change it will bypass
.seen-check, and it will be processed successfully again. Then you can
strip another byte and see if it was processed successfully (for
example, as an adversary, you see if some message/file appears somewhere
after you sent the modified encrypted packet). And do that until you
strip off all junk padding, thus knowing the real payload's 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.

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.

>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 :-)

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