simon-git: putty (main): Simon Tatham
Commits to Tartarus hosted VCS
tartarus-commits at lists.tartarus.org
Fri Aug 27 21:42:12 BST 2021
TL;DR:
59409d09 Make mp_unsafe_mod_integer not be unsafe.
23431f8f Add some tests of Miller-Rabin to cryptsuite.
6520574e Side-channel-safe rewrite of the Miller-Rabin test.
3bb12dff Make pcs_set_oneshot even more one-shot.
1c78d18a sclog: wrap memmove.
d8fda3b6 testsc: add side-channel test of probabilistic prime gen.
Repository: https://git.tartarus.org/simon/putty.git
On the web: https://git.tartarus.org/?p=simon/putty.git
Branch updated: main
Committer: Simon Tatham <anakin at pobox.com>
Date: 2021-08-27 21:42:12
commit 59409d0947ec6d0dc11b4bda8296f68ff088f0f3
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=59409d0947ec6d0dc11b4bda8296f68ff088f0f3;hp=22fab7837660fe2cf6ee08b10bd6696cc2653024
Author: Simon Tatham <anakin at pobox.com>
Date: Fri Aug 27 17:43:40 2021 +0100
Make mp_unsafe_mod_integer not be unsafe.
I've moved it from mpunsafe.c into the main mpint.c, and renamed it
mp_mod_known_integer, because now it manages to avoid leaking
information about the mp_int you give it.
It can still potentially leak information about the small _modulus_
integer - hence the word 'known' in the new function name. This won't
be a problem in any existing use of the function, because it's used
during prime generation to check divisibility by all the small primes,
and optionally also check for residue 1 mod the RSA public exponent.
But all those values are well known and not secret.
This removes one source of side-channel leakage from prime generation.
crypto/mpint.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++
keygen/mpunsafe.c | 10 ------
keygen/mpunsafe.h | 7 -----
keygen/primecandidate.c | 6 ++--
mpint.h | 6 ++++
5 files changed, 90 insertions(+), 20 deletions(-)
commit 23431f8ff454aef29f25627bae2bc08c6dd69af2
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=23431f8ff454aef29f25627bae2bc08c6dd69af2;hp=59409d0947ec6d0dc11b4bda8296f68ff088f0f3
Author: Simon Tatham <anakin at pobox.com>
Date: Fri Aug 27 17:43:40 2021 +0100
Add some tests of Miller-Rabin to cryptsuite.
I'm about to rewrite the Miller-Rabin testing code, so let's start by
introducing a test suite that the old version passes, and then I can
make sure the new one does too.
keygen/millerrabin.c | 29 +++++++++++++++++------
sshkeygen.h | 8 +++++++
test/cryptsuite.py | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++
test/testcrypt.py | 2 +-
testcrypt.c | 12 ++++++++++
testcrypt.h | 2 ++
6 files changed, 112 insertions(+), 8 deletions(-)
commit 6520574e584351f6c3af1fabcb6951db8ea98066
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=6520574e584351f6c3af1fabcb6951db8ea98066;hp=23431f8ff454aef29f25627bae2bc08c6dd69af2
Author: Simon Tatham <anakin at pobox.com>
Date: Fri Aug 27 17:46:25 2021 +0100
Side-channel-safe rewrite of the Miller-Rabin test.
Thanks to Mark Wooding for explaining the method of doing this. At
first glance it seemed _obviously_ impossible to run an algorithm that
needs an iteration per factor of 2 in p-1, without a timing leak
giving away the number of factors of 2 in p-1. But it's not, because
you can do the M-R checks interleaved with each step of your whole
modular exponentiation, and they're cheap enough that you can do them
in _every_ step, even the ones where the exponent is too small for M-R
to be interested in yet, and then do bitwise masking to exclude the
spurious results from the final output.
keygen/millerrabin.c | 131 +++++++++++++++++++++++++++++++++++++--------------
sshkeygen.h | 4 +-
test/cryptsuite.py | 19 ++++++++
3 files changed, 116 insertions(+), 38 deletions(-)
commit 3bb12dff3b4e4e691fd413a6de642b339f99a072
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=3bb12dff3b4e4e691fd413a6de642b339f99a072;hp=6520574e584351f6c3af1fabcb6951db8ea98066
Author: Simon Tatham <anakin at pobox.com>
Date: Fri Aug 27 17:46:25 2021 +0100
Make pcs_set_oneshot even more one-shot.
Previously, it would generate a prime candidate, test it, and abort if
that candidate failed to be prime. Now, it's even willing to fail
_before_ generating a prime candidate, if the first attempt to even do
that is unsuccessful.
This doesn't affect the existing use case of pcs_set_oneshot, which is
during generation of a safe prime (as implemented by test/primegen.py
--safe), where you want to make a PrimeCandidateSource that can only
return 2p+1 for your existing prime p, and then abort if that fails
the next step of testing. In that situation, the PrimeCandidateSource
will never fail to generate its first output anyway.
But these changed semantics will become useful in another use I'm
about to find for one-shot mode.
keygen/primecandidate.c | 2 ++
1 file changed, 2 insertions(+)
commit 1c78d18acb20c5f4b47af7e9daec2bbc74826dc7
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=1c78d18acb20c5f4b47af7e9daec2bbc74826dc7;hp=3bb12dff3b4e4e691fd413a6de642b339f99a072
Author: Simon Tatham <anakin at pobox.com>
Date: Fri Aug 27 17:46:25 2021 +0100
sclog: wrap memmove.
I had a testsc run fail because of alignment-dependent control flow
divergence in a glibc function with 'memmove' in the name, which
appears to have been an accident of different memory allocation
between two runs of the test in question.
sclog was already giving special handling to memset for the same
reason, so it's no trouble to add memmove to the same list of
functions that are treated as an opaque primitive for logging
purposes.
test/sclog/sclog.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
commit d8fda3b6da78c5a62c77fe5d75b9a033ef94e882
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d8fda3b6da78c5a62c77fe5d75b9a033ef94e882;hp=1c78d18acb20c5f4b47af7e9daec2bbc74826dc7
Author: Simon Tatham <anakin at pobox.com>
Date: Fri Aug 27 17:46:25 2021 +0100
testsc: add side-channel test of probabilistic prime gen.
Now that I've removed side-channel leakage from both prime candidate
generation (via mp_unsafe_mod_integer) and Miller-Rabin, the
probabilistic prime generation system in this code base is now able to
get through testsc without it detecting any source of cache or timing
side channels. So you should be able to generate an RSA key (in which
the primes themselves must be secret) in a more hostile environment
than you could previously be confident of.
This is a bit counterintuitive, because _obviously_ random prime
generation takes a variable amount of time, because it has to keep
retrying until an attempt succeeds! But that's OK as long as the
attempts are completely independent, because then any timing or cache
information leaked by a _failed_ attempt will only tell an attacker
about the numbers used in the failed attempt, and those numbers have
been thrown away, so it doesn't matter who knows them. It's only
important that the _successful_ attempt, from generating the random
candidate through to completing its verification as (probably) prime,
should be side-channel clean, because that's the attempt whose data is
actually going to be turned into a private key that needs to be kept
secret.
(In particular, this means you have to avoid the old-fashioned
strategy of generating successive prime candidates by incrementing a
starting value until you find something not divisible by any small
prime, because the number of iterations of that method would be a
timing leak. Happily, we stopped doing that last year, in commit
08a3547bc54051e: now every candidate integer is generated
independently, and if one fails the initial checks, we throw it away
and start completely from scratch with a fresh random value.)
So the test harness works by repeatedly running the prime generator in
one-shot mode until an attempt succeeds, and then resetting the
random-number stream to where it was just before the successful
attempt. Then we generate the same prime number again, this time with
the sclog mechanism turned on - and then, we compare it against the
version we previously generated with the same random numbers, to make
sure they're the same. This checks that the attempts really _are_
independent, in the sense that the prime generator is a pure function
of its random input stream, and doesn't depend on state left over from
previous attempts.
testsc.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++++
unix/CMakeLists.txt | 2 +-
2 files changed, 92 insertions(+), 1 deletion(-)
More information about the tartarus-commits
mailing list