simon-git: putty (master): Simon Tatham

Mon Mar 2 18:52:19 GMT 2020

TL;DR:
  3ea69c29 mpint: clean up handling of uintmax_t.
  289d8873 Fix mp_{eq,hs}_integer(tiny, huge).
  a82e1da0 Fix GUI config crash due to missing Ed448.
  bf3aa818 Fix occasional hang in SPP_MAURER_COMPLEX logic.
  68ebcd7b Provable primes: be more careful about max_bits_needed.
  ead93558 Fix comment in old probabilistic prime algorithm.

Repository:     https://git.tartarus.org/simon/putty.git
On the web:     https://git.tartarus.org/?p=simon/putty.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2020-03-02 18:52:19

commit 3ea69c290e8764282d3c52f351dfdc166e926590
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=3ea69c290e8764282d3c52f351dfdc166e926590;hp=a085acbadf829ac5b426323ca98058d6aa4048ba
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 2 18:34:52 2020 +0000

    mpint: clean up handling of uintmax_t.

    Functions like mp_copy_integer_into, mp_add_integer_into and
    mp_hs_integer all take an ordinary C integer in the form of a
    uintmax_t, and perform an operation between that and an mp_int. In
    order to do that, they have to break it up into some number of
    BignumInt, via bit shifts.

    But in C, shifting by an amount equal to or greater than the width of
    the type is undefined behaviour, and you risk the compiler generating
    nonsense or complaining at compile time. I did various dodges in those
    functions to try to avoid that, but didn't manage to use the same
    idiom everywhere. Sometimes I'd leave the integer in its original form
    and shift it right by increasing multiples of BIGNUM_INT_BITS;
    sometimes I'd shift it down in place every time. And mostly I'd do the
    conditional shift by checking against sizeof(n), but once I did it by
    shifting by half the word and then the other half.

    Now refactored so that there's a pair of functions to shift a
    uintmax_t left or right by BIGNUM_INT_BITS in what I hope is a UB-safe
    manner, and changed all the code I could find to use them.

 mpint.c | 56 ++++++++++++++++++++++++++++++++++++++++----------------
 1 file changed, 40 insertions(+), 16 deletions(-)

commit 289d8873ec4de802f00a6aaa2d60013d4d911cc1
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=289d8873ec4de802f00a6aaa2d60013d4d911cc1;hp=3ea69c290e8764282d3c52f351dfdc166e926590
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 2 18:42:31 2020 +0000

    Fix mp_{eq,hs}_integer(tiny, huge).

    The comparison functions between an mp_int and an integer worked by
    walking along the mp_int, comparing each of its words to the
    corresponding word of the integer. When they ran out of mp_int, they'd
    stop.

    But this overlooks the possibility that they might not have run out of
    _integer_ yet! If BIGNUM_INT_BITS is defined to be less than the size
    of a uintmax_t, then comparing (say) the uintmax_t 0x8000000000000001
    against a one-word mp_int containing 0x0001 would return equality,
    because it would never get as far as spotting the high bit of the
    integer.

    Fixed by iterating up to the max of the number of BignumInts in the
    mp_int and the number that cover a uintmax_t. That means we have to
    use mp_word() instead of a direct array lookup to get the mp_int words
    to compare against, since now the word indices might be out of range.

 mpint.c            | 10 ++++++----
 test/cryptsuite.py | 13 +++++++++++++
 2 files changed, 19 insertions(+), 4 deletions(-)

commit a82e1da0b7d503e53a1d53fb40cdac0284fc104e
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=a82e1da0b7d503e53a1d53fb40cdac0284fc104e;hp=289d8873ec4de802f00a6aaa2d60013d4d911cc1
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 2 18:43:00 2020 +0000

    Fix GUI config crash due to missing Ed448.

    How embarrassing - this morning's triumphant push of a shiny new
    public-key method managed to break the entire GUI configuration system
    so that it dereferences a null pointer during setup. That's what I get
    for only testing the crypto side.

    settings.c generates a preference list of host-key enum values that
    included HK_ED448. So then hklist_handler() in config.c tries to look
    that id up in its list of names, and doesn't find one, because I
    forgot to add it there. Now reinstated.

 config.c | 1 +
 1 file changed, 1 insertion(+)

commit bf3aa818e490245622555a37d2f09093a85bfe50
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=bf3aa818e490245622555a37d2f09093a85bfe50;hp=a82e1da0b7d503e53a1d53fb40cdac0284fc104e
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 2 18:49:07 2020 +0000

    Fix occasional hang in SPP_MAURER_COMPLEX logic.

    I generated a list of sizes in bits for factors of p-1, knowing a
    range of bit sizes that I wanted their product to fall in. But I
    forgot that when you multiply together two or more numbers of
    particular bit sizes, you can get more than one possible bit size
    back. My code was estimating at the low end of the possible range, so
    sometimes it would end up with more bits of the output prime specified
    than it expected, and be left without enough variable bits to actually
    be able to find a prime somewhere in the remaining space.

    Now when I'm planning the factor list, I compute both the min and max
    sizes of the product of the factors, and abort if any part of the
    possible range is outside the safe zone.

 sshprime.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

commit 68ebcd7b86aa161abdf7151d9be9101538cf34f3
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=68ebcd7b86aa161abdf7151d9be9101538cf34f3;hp=bf3aa818e490245622555a37d2f09093a85bfe50
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 2 18:49:21 2020 +0000

    Provable primes: be more careful about max_bits_needed.

    When judging how many bits of the generated prime we can afford to
    consume with factors of p-1 and still have enough last few bits to
    vary to find an actual prime in the range, I started by setting
    max_bits_needed to the total size of the required output number, and
    then subtracting a safety margin.

    But that doesn't account for the fact that some bits may _already_
    have been used by prior requirements from the PrimeCandidateSource,
    such as the 'firstbits' used in RSA generation, or the 160-bit factor
    of p-1 used in DSA.

    So now we start by initialising max_bits_needed by asking the PCS how
    many bits of entropy it still has left, and making sure not to reduce
    _that_ by too much. Should fix another cause of hangs during prime
    generation.

    (Also, while I'm here, I've tweaked one of the compiled-out
    diagnostics so that it reports how many bits it _does_ have left once
    it starts trying to find a prime. That should make it easier to spot
    any further problems in this area.)

 sshprime.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

commit ead935588285b49aae904f132df5071d44b8b7c4
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=ead935588285b49aae904f132df5071d44b8b7c4;hp=68ebcd7b86aa161abdf7151d9be9101538cf34f3
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Mar 2 18:51:39 2020 +0000

    Fix comment in old probabilistic prime algorithm.

    We're no longer doing the delta step at all, and even if we were, it's
    not really part of _that_ particular algorithm - candidate selection
    is centralised between all of them.

 sshprime.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)