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
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
