Control: severity -1 normal Hello Jan,
Thanks for the detailed explanation and for pushing your integration tests. I have pushed them[0] to the main repo (with the same changes we discussed in the rsakeyfind MR) making use of the "-t 50" parameter. So the package can have integ tests even before we get to solve the problem, I hope you don't mind. It looks like it's not gonna be very easy to debug this, and considering the way the package works[1], I'm lowering the severity to normal and I'll likely not gonna try to fix it (anybody reading this please feel free to submit MRs). In order to debug this you will probably have to get a stacktrace for two runs of aeskeyfind against the same dump file, one for each version of glibc (or whatever is the suspect), and compare them to see where's the difference in computation occurring for the xor variables. This is gonna be quite complicated as those variables get changed inside a loop (for the chunks of memory retrieved) and you're only interested in one of those iterations (maybe the dump can be simplified to contain only the key). I bet it would be an interesting and cool investigation, but one would have to have enough time for it, so don't feel pressured to do so, the fact that you found the issue and contributed the integ tests already put the package in a much better position. [0] https://salsa.debian.org/pkg-security-team/aeskeyfind/-/commit/a282f8ed7afb207a7a713ac0612b3cdba860fb48 [1] The paper where this software comes from starts from the principle that the key to be retrieved is corrupted (cold memory) and so it has some heuristics to try to find the key, the threshold parameter is related to that and so users are expected to understand they need to tweak "-t" in their investigations. https://citp.princeton.edu/our-work/memory/ Thanks, -- Samuel Henrique <samueloph>
