Kernel 6.1.1 brokenkey issue - fixed via new cryptsetup or not fixed?

Technical issues/questions of an intermediate or advanced nature.
User avatar
Rava
Contributor
Contributor
Posts: 5401
Joined: 11 Jan 2011, 02:46
Distribution: XFCE 5.01 x86_64 + 4.0 i586
Location: Forests of Germany

Kernel 6.1.1 brokenkey issue - fixed via new cryptsetup or not fixed?

Post#1 by Rava » 25 Dec 2022, 04:57

i was asking in the kernel thread which stable kernel would support nftables and got this reply
beny wrote:
24 Dec 2022, 14:23
you can use the blaze 6.1.1 kernel
Blaze's kernel 6.1.1 x86-64 is posted here Porteus Kernel Builder (Post by Blaze #92288)

Now looking up the kernel.org Changelog via https://cdn.kernel.org/pub/linux/kernel ... eLog-6.1.1

There it says this
NEWKEY is still broken: If for BROKENKEY 32 bytes were
specified, a brute force attacker knowing the key properties would only
need to try at most 2^(16*8) keys, as if the key was only 16 bytes long.

The security issue is a result of the combination of limiting the input
range to hex-ascii and using memcpy() instead of hex2bin(). It could
have been fixed either by allowing binary input or using hex2bin() (and
doubling the ascii input key length). This patch implements the latter.
Is that a serious issue or is Blaze 6.1.1 kernel patched and thus the described issue doesn't apply to his kernel?

E.g. does what Blaze mentioned in "Note 3" fix the issue?
Blaze wrote:
24 Dec 2022, 10:50
6.1.1 <-- NEW : "All patches" patching was done.
64bit-ALL-kernel6.1.1.tar (~132 M)
[…]
Note 3: A new cryptsetup (version 2.3.5: presented by @ncmprhnsbl)
(He provided no further link to the "new cryptsetup" so I could not look up the details myself, hence this post.)
Cheers!
Yours Rava