Package: aeskeyfind Version: 1:1.0-8 Severity: important Tags: upstream Dear Maintainer,
I was in the process of creating autopkgtests for aeskeyfind and discovered, that using aeskeyfind with kernel 5.10.0.6 and glibc 2.31-11 leads to wrong results. Existing AES-keys are not found, although they are and extracted by aeskeyfind on kernel 5.4.0.73 and glibc 2.27 at least. Further testing revelead, that the values of the variables named xor_count_128 and xor_count_256 are higher in the failing setup. This seems to stem from the following two functions: https://salsa.debian.org/pkg-security-team/aeskeyfind/-/blob/debian/master/util.h#L25 https://salsa.debian.org/pkg-security-team/aeskeyfind/-/blob/debian/master/util.h#L25 Unfortunately there is no upstream maintainer, so that I file a bug on Debian's BTS, since it is a serious issue for the functionality of the package. A temporary workaround is to set the threshold higher to overcome the miscalculated xor_count_*. Best regards, Jan -- System Information: Debian Release: bullseye/sid APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-6-amd64 (SMP w/1 CPU thread) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages aeskeyfind depends on: ii libc6 2.31-11 aeskeyfind recommends no packages. aeskeyfind suggests no packages. -- no debconf information
