Connection hangs after delivery of 256GB of data

[AlexPeshkoff]

ChaCha wire encryption, used by default since FB4, is using 32-bit counter. When counter overflows secure packets delivery becomes impossible without reconnect.

[AlexPeshkoff]

Added configuration parameter CounterSize (in ChaCha.conf). Setting it to 64 makes it use 64-bit counter which is able to exchange with very big volume of data, practically unlimited.

Using this setting makes firebird server incompatible with 4.0.0 client

[mrotteveel]

This is not an appropriate fix. The client has no way to know to know the counter size the server expects. In addition, this is no longer ChaCha20 as defined in RFC-7539, which makes it harder to support. If a bigger counter is needed, then a new variant of ChaCha needs to be added with a separate name, to distinguish it from the standard 32-bit counter variant.

[AlexPeshkoff]

The client has a way to know the counter size the server expects. IV (nonce) is sent to client, and depending on it's size client does know what counter size should be used.

What about use of .conf for choosing chacha variant: we are not the only one who met this problem, see for example https://libsodium.gitbook.io/doc/advanced/stream_ciphers/chacha20. Pay attention - "The original ChaCha20 cipher with a 64-bit nonce". I.e. it has all reasons to be called 'ChaCha'.

And I disagree with you about "harder to support" - having single plugin with reasonable parameter much simpler to support compared with duplicated copies of same code.

[mrotteveel]

On 2021-12-13 09:53, Alexander Peshkov wrote: The client has a way to know the counter size the server expects. IV (nonce) is sent to client, and depending on it's size client does know what counter size should be used. What about use of .conf for choosing chacha variant: we are not the only one who met this problem, see for example https://libsodium.gitbook.io/doc/advanced/stream_ciphers/chacha20. Pay attention - And I disagree with you about "harder to support" - having single plugin with reasonable parameter much simpler to support compared with duplicated copies of same code.

It is harder to support, because for example Java only supports the standardized ChaCha20 with 32-bit counter. And given a client can't know in advance whether or not the server is configured with a 64-bit counter, Jaybird could incorrectly try to offer ChaCha, but then can't use it because the server wants to use a 64-bit counter which I don't actually support, and I either have to use the less secure ARC4, or maybe even forgo encryption entirely, which then means that - depending on the server config - Jaybird cannot connect at all. Having a separate plugin **name** (which IMO doesn't necessarily implies entirely separate plugin **code**), allows the server to prioritize ChaCha with 64 bit counter, while a client that only supports the standard ChaCha20 (with 32-bit counter) will still able to establish a connection using that plugin. Standard ChaCha20 (with 32-bit counter) as defined in RFC-7539[1] is a different encryption than ChaCha with 64-bit counter, and thus needs to be named separately. [1]: https://datatracker.ietf.org/doc/html/rfc7539#section-2.4

[AlexPeshkoff]

Java only supports ... ChaCha20 with 32-bit counter

That's what you could say at once instead of loosing so many words... Will rework - never new that original for one people variant is not supported by others :-)

[aafemt]

May I suggest to leave ChaCha as is and just move it deeper in configuration so rc4 is used by default with added warning that ChaCha while is "more secure" cannot be used for long lasting connections?