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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
