On 10-02-2020 17:19, Alex Peshkoff via Firebird-devel wrote:
On 2020-01-26 16:01, Mark Rotteveel wrote:
Maybe instead the key should be stretched to 256 bit (eg using SHA256) instead? This would ensure that a 256 bit key is always used, and allows interoperability with implementations that only support 256 bit keys.

In addition, this would reduce key length for auth plugins generating longer keys while not just discarding bits.

In https://tools.ietf.org/html/rfc7539 I see the following:

    The ChaCha algorithm described here uses a 256-bit key.  The original
    algorithm also specified 128-bit keys and 8- and 12-round variants,
    but these are out of scope for this document.

I.e. I tend to agree that no matter of the fact that 128-bit is also absolutely acceptable variant of ChaCha 256-bit key is often treated as preferred one. Yes, we can stretch 20-byte key in some way and even avoid discarding bits using sha or some other way (128-bit key is just self concatenated in ChaCha).

The only place that appears to have not one answer - what to do with exactly 128-bit key? If people provide that key from non-standard plugin they may expect using it according to chacha specification. On the other hand we loose generic approach and have all problems described by you earlier if we use std 128-bit key for chacha. Currently we do have 128-bit keys, they come from win_sspi.

I see two possibilities: always stretch to 256 bit, and use the 256 bit variant of ChaCha, or define two plugins: chacha20-256 and chacha20-128, and define how keys should be stretched/reduced for both cases (eg using SHA-256, or using PBKDF2 or something like that). Then the client can select an appropriate/desired variant.

Mark Rotteveel

Firebird-Devel mailing list, web interface at 

Reply via email to