simon-git: putty (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  e800e531 Move fuzzterm.c into the test subdirectory.
  46fbe375 Switch to a fixed-window strategy for monty_pow.
  cd60a602 Stop using short exponents for Diffie-Hellman.

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-11-28 13:03:28

commit e800e5310cb382bd00dfdf37500ce3f1cbc3d253
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=e800e5310cb382bd00dfdf37500ce3f1cbc3d253;hp=cbc723bf9daa9990981aca047c65420379effeb7
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Nov 28 11:15:46 2021 +0000

    Move fuzzterm.c into the test subdirectory.
    
    It's unquestionably a test program, and I'm generally clearing those
    out of the top level. I only missed it in the last clearout because I
    was looking for things with 'test' in the name.

 fuzzterm.c => test/fuzzterm.c | 0
 unix/CMakeLists.txt           | 2 +-
 2 files changed, 1 insertion(+), 1 deletion(-)

commit 46fbe375bf1e019154314d13bd7b38334783240d
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=46fbe375bf1e019154314d13bd7b38334783240d;hp=e800e5310cb382bd00dfdf37500ce3f1cbc3d253
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Nov 28 12:01:19 2021 +0000

    Switch to a fixed-window strategy for monty_pow.
    
    Instead of the basic square-and-multiply strategy which requires a
    square and a multiply per exponent bit (i.e. two modular
    multiplications per bit in total), we instead reduce to a square per
    exponent bit and an extra multiply only every 5 bits, because the
    value we're multiplying in is derived from 5 of the exponent bits at
    once via a table lookup.
    
    To avoid the obvious side-channel leakage of a literal table lookup,
    we read the whole table every time, mp_selecting the right value into
    the multiplication input. This isn't as slow as it sounds when the
    alternative is four entire modular multiplications! In my testing,
    this commit speeds up large modpows by a factor of just over 1.5, and
    it still gets a clean pass from 'testsc'.

 crypto/mpint.c | 119 +++++++++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 95 insertions(+), 24 deletions(-)

commit cd60a602f541ac44aecd207f4e055279b86d1898
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=cd60a602f541ac44aecd207f4e055279b86d1898;hp=46fbe375bf1e019154314d13bd7b38334783240d
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Nov 28 12:10:42 2021 +0000

    Stop using short exponents for Diffie-Hellman.
    
    I recently encountered a paper [1] which catalogues all kinds of
    things that can go wrong when one party in a discrete-log system
    invents a prime and the other party chooses an exponent. In
    particular, some choices of prime make it reasonable to use a short
    exponent to save time, but others make that strategy very bad.
    
    That paper is about the ElGamal encryption scheme used in OpenPGP,
    which is basically integer Diffie-Hellman with one side's key being
    persistent: a shared-secret integer is derived exactly as in DH, and
    then it's used to communicate a message integer by simply multiplying
    the shared secret by the message, mod p.
    
    I don't _know_ that any problem of this kind arises in the SSH usage
    of Diffie-Hellman: the standard integer DH groups in SSH are safe
    primes, and as far as I know, the usual generation of prime moduli for
    DH group exchange also picks safe primes. So the short exponents PuTTY
    has been using _should_ be OK.
    
    However, the range of imaginative other possibilities shown in that
    paper make me nervous, even so! So I think I'm going to retire the
    short exponent strategy, on general principles of overcaution.
    
    This slows down 4096-bit integer DH by about a factor of 3-4 (which
    would be worse if it weren't for the modpow speedup in the previous
    commit). I think that's OK, because, firstly, computers are a lot
    faster these days than when I originally chose to use short exponents,
    and secondly, more and more implementations are now switching to
    elliptic-curve DH, which is unaffected by this change (and with which
    we've always been using maximum-length exponents).
    
    [1] On the (in)security of ElGamal in OpenPGP. Luca De Feo, Bertram
    Poettering, Alessandro Sorniotti. https://eprint.iacr.org/2021/923

 crypto/diffie-hellman.c | 19 +------------------
 ssh.h                   |  2 +-
 ssh/kex2-client.c       |  4 ++--
 ssh/kex2-server.c       |  2 +-
 test/testcrypt-func.h   |  2 +-
 5 files changed, 6 insertions(+), 23 deletions(-)