simon-git: putty (master): Simon Tatham

Sun Feb 23 15:49:56 GMT 2020

TL;DR:
  921118db Fix handling of large RHS in mp_add_integer_into.
  55ed53d4 Fix key-component names for ed25519.
  791f1cc0 cmdgen: document --dump in the online help.
  82df8371 Test passing null pointers to mp_divmod_into.
  9af72ca1 Move init_primes_array out into its own file.
  dec79cf1 Start a file of 'unsafe' mp_int functions.
  18678ba9 mpint: add mp_[lr]shift_safe_into functions.
  d4a4111f mpint: add mp_lshift_fixed().
  957f1408 mpint: add mp_random_upto().
  2debb352 mpint: add a gcd function.
  dfddd138 testcrypt: allow random_read() to use a full PRNG.
  da3bc3d9 Refactor generation of candidate integers in primegen.
  13f594f0 Move invent_firstbits() into sshrsag.c.
  5a9bfca3 RSA generation: change exponent to 2^16+1.

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-02-23 15:49:56

commit 921118dbea743cc1ba78e21b01924343a077064f
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=921118dbea743cc1ba78e21b01924343a077064f;hp=c18e5dc8fbfd33d3544fee8977fc590339416b7e
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Feb 19 19:08:51 2020 +0000

    Fix handling of large RHS in mp_add_integer_into.

    While looking over the code for other reasons, I happened to notice
    that the internal function mp_add_masked_integer_into was using a
    totally wrong condition to check whether it was about to do an
    out-of-range right shift: it was comparing a shift count measured in
    bits against BIGNUM_INT_BYTES.

    The resulting bug hasn't shown up in the code so far, which I assume
    is just because no caller is passing any RHS to mp_add_integer_into
    bigger than about 1 or 2. And it doesn't show up in the test suite
    because I hadn't tested those functions. Now I am testing them, and
    the newly added test fails when built for 16-bit BignumInt if you back
    out the actual fix in this commit.

 mpint.c            |  5 +++--
 test/cryptsuite.py | 16 ++++++++++++++++
 2 files changed, 19 insertions(+), 2 deletions(-)

commit 55ed53d4981db972bc96788c0e69aea0d0bb0814
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=55ed53d4981db972bc96788c0e69aea0d0bb0814;hp=921118dbea743cc1ba78e21b01924343a077064f
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 23 11:58:03 2020 +0000

    Fix key-component names for ed25519.

    When I implemented the puttygen --dump option recently, my aim was
    that all the components related to the public key would have names
    beginning with "public_", and the private components' names should
    begin with "private_". Anything not beginning with either is a
    _parameter of the system_, i.e. something that can safely be shared
    between multiple users' key pairs without giving any of them the
    ability to break another's key.

    (In particular, in integer DSA, p, q and g are unprefixed, y is
    labelled as public, and x as private. In principle, p,q,g are safe to
    share; I think the only reason nobody bothers is that standardisation
    is more difficult than generating a fresh prime every time. In
    elliptic-curve DSA, the effort equation reverses, because finding a
    good curve is a pain, so everybody standardises on one of a small
    number of well-known ones.)

    Anyway. This is all very well except that I left the 'public' prefix
    off the EdDSA x and y values. Now fixed.

 sshecc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

commit 791f1cc0680eb2108a395303f89a4dbd2dfd6ef2
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=791f1cc0680eb2108a395303f89a4dbd2dfd6ef2;hp=55ed53d4981db972bc96788c0e69aea0d0bb0814
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 23 12:02:19 2020 +0000

    cmdgen: document --dump in the online help.

    There's always something.

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

commit 82df83719a0c790f8c71167e22708a46bc8267ab
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=82df83719a0c790f8c71167e22708a46bc8267ab;hp=791f1cc0680eb2108a395303f89a4dbd2dfd6ef2
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Feb 18 18:55:56 2020 +0000

    Test passing null pointers to mp_divmod_into.

    I've got opt_val_mpint already in the test system, so it makes
    sense to use it.

 test/cryptsuite.py | 12 ++++++++++++
 testcrypt.h        |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

commit 9af72ca1e82483c1c686f5236f658a73e22ba087
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=9af72ca1e82483c1c686f5236f658a73e22ba087;hp=82df83719a0c790f8c71167e22708a46bc8267ab
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 23 14:08:57 2020 +0000

    Move init_primes_array out into its own file.

    Mostly because I just had a neat idea about how to expose that large
    mutable array without it being a mutable global variable: make it a
    static in its own module, and expose only a _pointer_ to it, which is
    const-qualified.

    While I'm there, changed the name to something more descriptive.

 Recipe        | 13 ++++++++-----
 smallprimes.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 sshkeygen.h   | 12 ++++++++++++
 sshprime.c    | 44 +++++++++-----------------------------------
 4 files changed, 73 insertions(+), 40 deletions(-)

commit dec79cf152b6e713bf764bdaaa8272c1272f411d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=dec79cf152b6e713bf764bdaaa8272c1272f411d;hp=9af72ca1e82483c1c686f5236f658a73e22ba087
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Feb 20 18:02:15 2020 +0000

    Start a file of 'unsafe' mp_int functions.

    Unlike the ones in mpint.c proper, these are not intended to respect
    the constant-time guarantees. They're going to be the kind of thing
    you use in key generation, which is too random to be constant-time in
    any case.

    I've arranged several precautions to try to make sure these functions
    don't accidentally get linked into the main SSH application, only into
    key generators:

     - declare them in a separate header with "unsafe" in the name

     - put "unsafe" in the name of every actual function

     - don't even link the mpunsafe.c translation unit into PuTTY proper

     - in fact, define global symbols of the same name in that file and
       the SSH client code, so that there will be a link failure if we
       ever try to do it by accident

    The initial contents of the new source file consist of the subroutine
    mp_mod_short() that previously lived in sshprime.c (and was not in
    mpint.c proper precisely because it was unsafe). While I'm here, I've
    turned it into mp_unsafe_mod_integer() and let it take a modulus of up
    to 32 bits instead of 16.

    Also added some obviously useful functions to shrink an mpint to the
    smallest physical size that can hold the contained number (rather like
    bn_restore_invariant in the old Bignum system), which I expect to be
    using shortly.

 Recipe           |  2 +-
 mpint.c          |  2 +-
 mpint_i.h        |  3 +++
 mpunsafe.c       | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 mpunsafe.h       | 46 +++++++++++++++++++++++++++++++++++++++++++++
 ssh2kex-client.c |  6 ++++++
 sshprime.c       | 22 +++-------------------
 7 files changed, 117 insertions(+), 21 deletions(-)

commit 18678ba9bc42c497355d5f53831e46246532a0a9
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=18678ba9bc42c497355d5f53831e46246532a0a9;hp=dec79cf152b6e713bf764bdaaa8272c1272f411d
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Feb 18 18:55:56 2020 +0000

    mpint: add mp_[lr]shift_safe_into functions.

    There was previously no safe left shift at all, which is an omission.
    And rshift_safe_into was an odd thing to be missing, so while I'm
    here, I've added it on the basis that it will probably be useful
    sooner or later.

 mpint.c            | 54 +++++++++++++++++++++++++++++++++++++++++++++++++++---
 mpint.h            |  9 ++++++++-
 test/cryptsuite.py | 10 ++++++++++
 testcrypt.h        |  2 ++
 4 files changed, 71 insertions(+), 4 deletions(-)

commit d4a4111fec6a8fb5f1b9f9967bda7999950af6c3
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=d4a4111fec6a8fb5f1b9f9967bda7999950af6c3;hp=18678ba9bc42c497355d5f53831e46246532a0a9
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Feb 21 19:51:31 2020 +0000

    mpint: add mp_lshift_fixed().

    This is a version of mp_lshift_fixed_into() which allocates the output
    number, which it can do because you know the size of the original
    number and are allowed to treat the shift count as non-secret.

    (By contrast, mp_lshift_safe() would be a nonsensical function - if
    you're trying to keep the shift count secret, you _can't_ use it as a
    parameter of memory allocation! In that situation you have no choice
    but to allocate memory based on a fixed upper bound.)

 mpint.c | 8 ++++++++
 mpint.h | 1 +
 2 files changed, 9 insertions(+)

commit 957f14088f471b2cb0ff9f82e8ee99ca5586313d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=957f14088f471b2cb0ff9f82e8ee99ca5586313d;hp=d4a4111fec6a8fb5f1b9f9967bda7999950af6c3
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 23 14:45:19 2020 +0000

    mpint: add mp_random_upto().

    This is a third random-number generation function, with an API in
    between the too-specific mp_random_bits and the too-general
    mp_random_in_range. Now you can generate a value between 0 and n
    without having to either make n a power of 2, or tediously allocate a
    zero mp_int to be the lower limit for mp_random_in_range.

    Implementation is done by sawing the existing mp_random_in_range into
    two pieces and exposing the API between them.

 mpint.c | 21 ++++++++++++++-------
 mpint.h |  3 +++
 2 files changed, 17 insertions(+), 7 deletions(-)

commit 2debb352b0ce2e5da982689b2514d96df04ea782
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=2debb352b0ce2e5da982689b2514d96df04ea782;hp=957f14088f471b2cb0ff9f82e8ee99ca5586313d
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Feb 18 18:55:57 2020 +0000

    mpint: add a gcd function.

    This is another application of the existing mp_bezout_into, which
    needed a tweak or two to cope with the numbers not necessarily being
    coprime, plus a wrapper function to deal with shared factors of 2.

    It reindents the entire second half of mp_bezout_into, so the patch is
    best viewed with whitespace differences ignored.

 mpint.c            | 254 +++++++++++++++++++++++++++++++++++------------------
 mpint.h            |  19 ++++
 test/cryptsuite.py |  42 +++++++++
 testcrypt.h        |   3 +
 4 files changed, 233 insertions(+), 85 deletions(-)

commit dfddd1381b45b893998a3123ffde2219142c105a
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=dfddd1381b45b893998a3123ffde2219142c105a;hp=2debb352b0ce2e5da982689b2514d96df04ea782
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Feb 19 19:12:59 2020 +0000

    testcrypt: allow random_read() to use a full PRNG.

    This still isn't the true random generator used in the live tools:
    it's deterministic, for repeatable testing. The Python side of
    testcrypt can now call random_make_prng(), which will instantiate a
    PRNG with the given seed. random_clear() still gets rid of it.

    So I can still have some tests control the precise random numbers
    received by the function under test, but for others (especially key
    generation, with its uncertainty about how much randomness it will
    actually use) I can just say 'here, have a seed, generate as much
    stuff from that seed as you need'.

 test/cryptsuite.py |  6 ++++++
 testcrypt.c        | 24 ++++++++++++++++++++++--
 testcrypt.h        |  1 +
 3 files changed, 29 insertions(+), 2 deletions(-)

commit da3bc3d927c72dcb55f11ebf8907e864f7ba6867
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=da3bc3d927c72dcb55f11ebf8907e864f7ba6867;hp=dfddd1381b45b893998a3123ffde2219142c105a
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 23 14:30:03 2020 +0000

    Refactor generation of candidate integers in primegen.

    I've replaced the random number generation and small delta-finding
    loop in primegen() with a much more elaborate system in its own source
    file, with unit tests and everything.

    Immediate benefits:

     - fixes a theoretical possibility of overflowing the target number of
       bits, if the random number was so close to the top of the range
       that the addition of delta * factor pushed it over. However, this
       only happened with negligible probability.

     - fixes a directional bias in delta-finding. The previous code
       incremented the number repeatedly until it found a value coprime to
       all the right things, which meant that a prime preceded by a
       particularly long sequence of numbers with tiny factors was more
       likely to be chosen. Now we select candidate delta values at
       random, that bias should be eliminated.

     - changes the semantics of the outermost primegen() function to make
       them easier to use, because now the caller specifies the 'bits' and
       'firstbits' values for the actual returned prime, rather than
       having to account for the factor you're multiplying it by in DSA.
       DSA client code is correspondingly adjusted.

    Future benefits:

     - having the candidate generation in a separate function makes it
       easy to reuse in alternative prime generation strategies

     - the available constraints support applications such as Maurer's
       algorithm for generating provable primes, or strong primes for RSA
       in which both p-1 and p+1 have a large factor. So those become
       things we could experiment with in future.

 Recipe             |   2 +-
 primecandidate.c   | 297 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 sshdssg.c          |   6 +-
 sshkeygen.h        |  53 +++++++++-
 sshprime.c         |  99 ++----------------
 test/cryptsuite.py |  75 ++++++++++++++
 testcrypt.c        |   2 +
 testcrypt.h        |   7 ++
 8 files changed, 444 insertions(+), 97 deletions(-)

commit 13f594f02d11b8a1d50496db7e530ac62c984f5c
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=13f594f02d11b8a1d50496db7e530ac62c984f5c;hp=da3bc3d927c72dcb55f11ebf8907e864f7ba6867
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Feb 23 15:31:05 2020 +0000

    Move invent_firstbits() into sshrsag.c.

    It's now a subroutine specific to RSA key generation, because the
    reworked PrimeCandidateSource system can handle the requirements of
    DSA generation automatically.

    The difference is that in DSA, one of the primes you generate is used
    as a factor in the generation of the other, so you can just pass q as
    a factor to pcs_require_residue_1, and it can get the range right by
    itself. But in RSA, neither prime is generated with the other one in
    mind; they're conceptually generated separately and independently,
    apart from that single joint restriction on their product.

    (I _could_ have added a feature to PrimeCandidateSource to specify a
    range for the prime more specifically than a few initial bits. But I
    didn't want to, because it would have been more complicated than doing
    it this way, and also slightly less good: if you invent one prime
    first and then constrain the range of the other one once you know the
    first, then you're not getting an even probability distribution of the
    possible _pairs_ of primes - you're privileging one over the other and
    skewing the distribution.)

 ssh.h      |   1 -
 sshprime.c | 111 ----------------------------------------------------------
 sshrsag.c  | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 115 insertions(+), 112 deletions(-)

commit 5a9bfca3d59ecf45466291cae4fb3db30f85157e
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=5a9bfca3d59ecf45466291cae4fb3db30f85157e;hp=13f594f02d11b8a1d50496db7e530ac62c984f5c
Author: Simon Tatham <anakin at pobox.com>
Date:   Mon Feb 17 19:53:19 2020 +0000

    RSA generation: change exponent to 2^16+1.

    This is probably overdue; everyone else seems to have settled on it as
    the preferred RSA key exponent for some time. And now that the
    descendant of mp_mod_short supports moduli up to 2^32 instead of 2^16,
    I can actually add it without the risk of assertion failures during
    prime generation.

 sshrsag.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)