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
