Hi Niels-- On Fri 2023-11-17 08:40:37 +0100, Niels Möller wrote: > Hi, that's a bug, let me give some background.
thanks for the explanation, that matches roughly what i expected from the comments in the source code. :) > But then that test was was broken in a later fix to add more input > validation. So the input validation happens deeper in the library, which results in a ciphertext-dependent branching path, right? > Durign the last few months, I've reorganized and expanding those test to > have that needed instrumentation only when tests are run as part of the > sc-*-test scripts, and those tests are also run by default if valgrind > is available, including by the x86_86 native builds in the ci system. thanks, i looked at 67aae9d2873bb56a7e7028709d2f2d4bd8897955 in particular, which seems to be a big part of this overhaul, including the introduction of _rsa_sec_decrypt (as exposed rsa-internal.h), which means those tests won't be able to be run against any older (pre-existing) version of the library. > make check EMULATOR='valgrind ...' right, this is how i got the tests to run in the first place. > (that will invoke test binaries with valgrind, but not test shell > scripts). > > So my advice would be to either ignore that error, or do further tests > on the master branch in the git repo. I'm looking into this because i'm trying to get the debian build daemons to run the tests with valgrind during build time to start with. But that means targeting the version(s) that are in debian, so testing the master branch won't work. > Then there are some details that are somewhat unclear. For the input > validation in rsa_sec_decrypt, since the cryptotext c is presumably > known by the attacker, it should not be a problem if the comparison c < > n leaks information about it. But then maybe the side-channel test > shouldn't mark the cryptotext input as secret at all, only the private > key? this latter simple approach is what i'm proposing now in https://bugs.debian.org/1056107 -- if we can get that merged in debian, that should give you native valgrind tests on all the platforms debian supports. If you think it would be useful, i can also look into what it would take to add runtime (as opposed to compile-time) tests on debian that use valgrind, to ensure that changes to any nettle dependencies (e.g. libgmp) don't re-introduce problems even if nettle hasn't had any direct updates. Please let me know what you think! --dkg
signature.asc
Description: PGP signature
_______________________________________________ nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se