ChaCha20 Rekey Frequency

[Chris Rapier]

I was wondering if there was something specific to the internal chacha20 
cipher as opposed to OpenSSL implementation.

I can't just change the block size because it breaks compatibility. I 
can do something like as a hack (though it would probably be better to 
do it with the compat function):

	if (strstr(enc->name, "chacha"))
	        *max_blocks = (u_int64_t)1 << (16*2);
	else if (enc->block_size >= 16)
		*max_blocks = (u_int64_t)1 << (enc->block_size*2);
	else
		*max_blocks = ((u_int64_t)1 << 30) / enc->block_size;
	if (state->rekey_limit)

to force it to reduce the rekey rate but I'm deeply unsure of what 
impact that would have on the security of the cipher as it's 
implemented. Especially the without-openssl internal implementation.

Chris

On 3/24/23 4:36 PM, Christian Weisgerber wrote:
> Chris Rapier:
> 
>> I'm wondering why the ChaCha20 cipher rekeys so frequently. At speed I'm
>> seeing rekeys every second or two. So I'm spending a large amount of
>> time in the rekey process. From what I've read about ChaCha20 it
>> shouldn't need to be rekeyed quite so frequently. Am I missing something
>> obvious?
> 
> That looks to be accidental.
> 
> The default rekey limit is set in ssh_set_newkeys():
>          /*
>           * The 2^(blocksize*2) limit is too expensive for 3DES,
>           * so enforce a 1GB limit for small blocksizes.
>           * See RFC4344 section 3.2.
>           */
>          if (enc->block_size >= 16)
>                  *max_blocks = (u_int64_t)1 << (enc->block_size*2);
>          else
>                  *max_blocks = ((u_int64_t)1 << 30) / enc->block_size;
>          if (state->rekey_limit)
>                  *max_blocks = MINIMUM(*max_blocks,
>                      state->rekey_limit / enc->block_size);
> 
> And the block size of chacha20-poly1305 is set to 8 bytes in
> ciphers[].  As a result, chacha20-poly1305 is rekeyed every 1GB of
> data as opposed to the 4GB limit of the AES-based ciphers.
>