openssh unix dev - Apr 2021 - Question about seqbuf in cipher-chacha-libcrypto.c

For various reasons I'd like to be able to understand how the block 
counter is handled cipher-chacha-libcrypto.c (mostly to test something 
that will probably go nowhere).

The initial block counter is set via
         /* Set Chacha's block counter to 1 */
         seqbuf[0] = 1;
         if (!EVP_CipherInit(ctx->main_evp, NULL, NULL, seqbuf, 1)
	...

Which I know means that the counter is set to 1 for the chunk of data 
corresponding to sequence number N via
	memset(seqbuf, 0, sizeof(seqbuf));
	POKE_U64(seqbuf + 8, seqnr);

I've been trying to figure out how I could set the counter to a 
different value say, for the 64th block of data in that chunk. I've 
tried doing a POKE_U32 in little endian order

#define POKE_U32_LITTLE(p, v)			\
         do { \
                 const u_int32_t __v = (v); \
		((u_char *)(p))[3] = (__v >> 24) & 0xff; \
                 ((u_char *)(p))[2] = (__v >> 16) & 0xff; \
                 ((u_char *)(p))[1] = (__v >> 8) & 0xff; \
                 ((u_char *)(p))[0] = __v & 0xff; \
         } while (0)

and then POKE_U32_LITTLE(seqbuf, block_count)

Unfortunately this doesn't seem to work. Any data I send with the block 
counter set to 0 comes out fine. Everything else is garbage. I *think* 
I'm doing the counter incorrectly but I'm at a loss.

Is there anything glaringly wrong in what I am doing? Is there a better 
way to determine the block count and setting the counter? If this is 
outside of the scope of discussion here I apologize.

Thanks

Chris

p.s. I tested whats in the counter section of the sequence buffer and 
got something that looks right but...

block count is 0
index 0: seqbuf[0] = 1
index 0: seqbuf[1] = 0
index 0: seqbuf[2] = 0
index 0: seqbuf[3] = 0
block count is 64
index 1: seqbuf[0] = 40
index 1: seqbuf[1] = 0
index 1: seqbuf[2] = 0
index 1: seqbuf[3] = 0
block count is 128
index 2: seqbuf[0] = 80
index 2: seqbuf[1] = 0
index 2: seqbuf[2] = 0
index 2: seqbuf[3] = 0
block count is 192
index 3: seqbuf[0] = c0
index 3: seqbuf[1] = 0
index 3: seqbuf[2] = 0
index 3: seqbuf[3] = 0
block count is 256
index 4: seqbuf[0] = 0
index 4: seqbuf[1] = 1
index 4: seqbuf[2] = 0
index 4: seqbuf[3] = 0

but everything above the 64th block is garbage.

On Wed, 21 Apr 2021, rapier wrote:
> For various reasons I'd like to be able to understand how the block
> counter is handled cipher-chacha-libcrypto.c (mostly to test something
> that will probably go nowhere).
I don't have any insight into the problem you're seeing except to note
that you don't seem to be doing anything obviously wrong.

As a suggestion, maybe try your experiment in the included portable
implementation of the cipher (i.e. cipher-chachapoly.c) - there's
less magic behind the scenes there compared to libcrypto and it's easier
to insert a bunch of printf()s to see what is actually being supplied to
the chacha20 primitive.

-d