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