Mailing List Archive: Question about seqbuf in cipher-chacha-libcrypto.c

Question about seqbuf in cipher-chacha-libcrypto.c

Apr 21, 2021, 1:16 PM

Post #1 of 3 (324 views)

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

Re: Question about seqbuf in cipher-chacha-libcrypto.c [ In reply to ]

djm at mindrot

Apr 21, 2021, 7:02 PM

Post #2 of 3 (324 views)

Permalink

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

Re: Question about seqbuf in cipher-chacha-libcrypto.c [ In reply to ]

rapier at psc

Apr 22, 2021, 8:31 AM

Post #3 of 3 (324 views)

Permalink

I'm about to port the changes over to that today. The way I look at it
I'm either screwing up the block count or I have some idiotic fencepost
issue. Mostly I'm trying to maximize throughput by parallelizing some
aspect of the encipherment process for chacha. I probably need to just
focus on the cipher itself but I wanted to try a different approach first.

Anyway, thanks for taking a look. If anything interesting comes up I'll
let people know.

Chris

On 4/21/21 10:02 PM, Damien Miller wrote:
> 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
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev