simon-git: putty (main): Simon Tatham

Commits to Tartarus hosted VCS tartarus-commits at lists.tartarus.org
Sun Dec 8 10:46:16 GMT 2024


TL;DR:
  c2d7ea8e Fix use of aligned_alloc() to be ASan-clean.
  fcdc804b Move some NTRU helper routines into a header file.
  f08da2b6 Separate NTRU Prime from the hybridisation layer.
  16629d3b Add more variants of SHAKE.
  b36d490b Give the kex selection list box a fixed height.
  e98615f0 New post-quantum kex: ML-KEM, and three hybrids of it.
  a3f22a2c Use the new 'HYBRID' names for the hybrid KEX packets.

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:           2024-12-08 10:46:16

commit c2d7ea8e67c462341e16d74e7a0ea42edd514635
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c2d7ea8e67c462341e16d74e7a0ea42edd514635;hp=7da3449586ea3e6faaa92663d32774e28cf4e2e3
Author: Simon Tatham <anakin at pobox.com>
Date:   Wed Dec 4 13:02:05 2024 +0100

    Fix use of aligned_alloc() to be ASan-clean.
    
    aligned_alloc() is used by testsc for all its memory allocation, to
    avoid false-positive timing variations that depend on memory alignment
    rather than actual secret data. But I'd forgotten that aligned_alloc
    requires the allocation size to be a multiple of the requested
    alignment.
    
    This showed up when I ran testsc in dry-run mode, and my normal build
    happened to be using ASan, which complains at the invalid allocation
    size. But it was theoretically a problem in all builds of
    testsc. (Though, as far as I'm aware, not practically; and it _only_
    affected testsc.)

 utils/memory.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

commit fcdc804b4f4cee6c5b6a1b436fbc6ec7db06ea3e
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=fcdc804b4f4cee6c5b6a1b436fbc6ec7db06ea3e;hp=c2d7ea8e67c462341e16d74e7a0ea42edd514635
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Dec 1 09:55:39 2024 +0000

    Move some NTRU helper routines into a header file.
    
    I'm going to want to use these again for ML-KEM, so let's put one copy
    of them where both algorithms can use it.

 crypto/ntru.c        | 56 ++++++----------------------------------------------
 crypto/smallmoduli.h | 54 ++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 60 insertions(+), 50 deletions(-)

commit f08da2b638256d73936122d638b177752d6d9838
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=f08da2b638256d73936122d638b177752d6d9838;hp=fcdc804b4f4cee6c5b6a1b436fbc6ec7db06ea3e
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Dec 7 19:21:57 2024 +0000

    Separate NTRU Prime from the hybridisation layer.
    
    Now ntru.c contains just the NTRU business, and kex-hybrid.c contains
    the system for running a post-quantum and a classical KEX and hashing
    together the results. In between them is a new small vtable API for
    the key encapsulation mechanisms that the post-quantum standardisation
    effort seems to be settling on.

 crypto/CMakeLists.txt |   1 +
 crypto/kex-hybrid.c   | 322 +++++++++++++++++++++++++++++++++++
 crypto/ntru.c         | 458 +++++++++++---------------------------------------
 defs.h                |   2 +
 ssh.h                 |  47 ++++++
 5 files changed, 467 insertions(+), 363 deletions(-)

commit 16629d3bbcae48a84780adbce9fc1a2995889f02
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=16629d3bbcae48a84780adbce9fc1a2995889f02;hp=f08da2b638256d73936122d638b177752d6d9838
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Dec 7 19:32:46 2024 +0000

    Add more variants of SHAKE.
    
    This adds a ssh_hashalg defining SHAKE256 with a 32-byte output, in
    addition to the 114-byte output we already have.
    
    Also, it defines a new API for using SHAKE128 and SHAKE256 in the more
    general form of an extendable output function, which is to say that
    you still have to put in all the input before reading any output, but
    once you start reading output you can just keep going until you have
    enough.
    
    Both of these will be needed in an upcoming commit implementing ML-KEM.

 crypto/sha3.c         | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++-
 defs.h                |  1 +
 ssh.h                 |  1 +
 test/cryptsuite.py    | 16 +++++++++++
 test/testcrypt-func.h |  4 +++
 test/testcrypt.c      |  9 +++++++
 6 files changed, 104 insertions(+), 1 deletion(-)

commit b36d490b5d0989ad791ace8cf98e36c4a82d5394
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=b36d490b5d0989ad791ace8cf98e36c4a82d5394;hp=16629d3bbcae48a84780adbce9fc1a2995889f02
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Dec 7 23:19:37 2024 +0000

    Give the kex selection list box a fixed height.
    
    It's actually the limiting factor on how small the whole PuTTY
    configuration dialog box can be: when KEX_MAX increased from 10 to 11
    with the introduction of NTRU, the config box got taller. Now it's
    back at 10.

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

commit e98615f0ba2d20607b13169e4dd9966da082139c
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=e98615f0ba2d20607b13169e4dd9966da082139c;hp=b36d490b5d0989ad791ace8cf98e36c4a82d5394
Author: Simon Tatham <anakin at pobox.com>
Date:   Sat Dec 7 19:33:39 2024 +0000

    New post-quantum kex: ML-KEM, and three hybrids of it.
    
    As standardised by NIST in FIPS 203, this is a lattice-based
    post-quantum KEM.
    
    Very vaguely, the idea of it is that your public key is a matrix A and
    vector t, and the private key is the knowledge of how to decompose t
    into two vectors with all their coefficients small, one transformed by
    A relative to the other. Encryption of a binary secret starts by
    turning each bit into one of two maximally separated residues mod a
    prime q, and then adding 'noise' based on the public key in the form
    of small increments and decrements mod q, again with some of the noise
    transformed by A relative to the rest. Decryption uses the knowledge
    of t's decomposition to align the two sets of noise so that the
    _large_ changes (which masked the secret from an eavesdropper) cancel
    out, leaving only a collection of small changes to the original secret
    vector. Then the vector of input bits can be recovered by assuming
    that those accumulated small pieces of noise haven't concentrated in
    any particular residue enough to push it more than half way to the
    other of its possible starting values.
    
    A weird feature of it is that decryption is not a true mathematical
    inverse of encryption. The assumption that the noise doesn't get large
    enough to flip any bit of the secret is only probabilistically valid,
    not a hard guarantee. In other words, key agreement can fail, simply
    by getting particularly unlucky with the distribution of your random
    noise! However, the probability of a failure is very low - less than
    2^-138 even for ML-KEM-512, and gets even smaller with the larger
    variants.
    
    An awkward feature for our purposes is that the matrix A, containing a
    large number of residues mod the prime q=3329, is required to be
    constructed by a process of rejection sampling, i.e. generating random
    12-bit values and throwing away the out-of-range ones. That would be a
    real pain for our side-channel testing system, which generally handles
    rejection sampling badly (since it necessarily involves data-dependent
    control flow and timing variation). Fortunately, the matrix and the
    random seed it was made from are both public: the matrix seed is
    transmitted as part of the public key, so it's not necessary to try to
    hide it. Accordingly, I was able to get the implementation to pass
    testsc by means of not varying the matrix seed between runs, which is
    justified by the principle of testsc that you vary the _secrets_ to
    ensure timing is independent of them - and the matrix seed isn't a
    secret, so you're allowed to keep it the same.
    
    The three hybrid algorithms, defined by the current Internet-Draft
    draft-kampanakis-curdle-ssh-pq-ke, include one hybrid of ML-KEM-768
    with Curve25519 in exactly the same way we were already hybridising
    NTRU Prime with Curve25519, and two more hybrids of ML-KEM with ECDH
    over a NIST curve. The former hybrid interoperates with the
    implementation in OpenSSH 9.9; all three interoperate with the fork
    'openssh-oqs' at github.com/open-quantum-safe/openssh, and also with
    the Python library AsyncSSH.

 config.c              |    2 +
 crypto/CMakeLists.txt |    1 +
 crypto/kex-hybrid.c   |   66 +++
 crypto/mlkem.c        | 1090 +++++++++++++++++++++++++++++++++++++++++++++++++
 crypto/mlkem.h        |   89 ++++
 putty.h               |    2 +
 settings.c            |    2 +
 ssh.h                 |   12 +
 ssh/transport2.c      |    8 +
 test/cryptsuite.py    |  212 ++++++++++
 test/testcrypt-enum.h |    6 +
 test/testcrypt-func.h |   30 ++
 test/testcrypt.c      |   42 +-
 test/testcrypt.py     |    2 +-
 test/testsc.c         |   58 +++
 15 files changed, 1618 insertions(+), 4 deletions(-)

commit a3f22a2cf9620de4e8d53ce3e7c9485c526eafce
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=a3f22a2cf9620de4e8d53ce3e7c9485c526eafce;hp=e98615f0ba2d20607b13169e4dd9966da082139c
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Dec 8 10:34:10 2024 +0000

    Use the new 'HYBRID' names for the hybrid KEX packets.
    
    draft-kampanakis-curdle-ssh-pq-ke defines the packet names
    SSH_MSG_KEX_HYBRID_INIT and SSH_MSG_KEX_HYBRID_REPLY. They have the
    same numbers as ECDH_INIT and ECDH_REPLY, and don't change anything
    else, so this is just a naming change. But I think it's a good one,
    because the post-quantum KEMs are less symmetric than ECDH (they're
    much more like Ben's RSA kex in concept, though very different in
    detail), and shouldn't try to pretend they're the same kind of thing.
    Also this enables logparse.pl to give a warning about the fact that
    one string in each packet contains two separate keys glomphed together.
    
    For the latter reason (and also because it's easier in my code
    structure) I've also switched to using the HYBRID naming for the
    existing NTRU + Curve25519 hybrid method, even though the
    Internet-Draft for that one still uses the ECDH names. Sorry, but I
    think it's clearer!

 contrib/logparse.pl | 40 ++++++++++++++++++++++++++++++++++++++++
 crypto/ecc-ssh.c    |  2 ++
 crypto/kex-hybrid.c |  3 +++
 ssh.h               |  9 +++++++++
 ssh/kex2-client.c   |  2 +-
 5 files changed, 55 insertions(+), 1 deletion(-)



More information about the tartarus-commits mailing list