simon-git: putty (master): Simon Tatham

Commits to Tartarus hosted VCS tartarus-commits at lists.tartarus.org
Fri Jan 18 19:47:24 GMT 2019


TL;DR:
  bf743bf8 Uppity: properly support _POSIX_VDISABLE in tty modes.
  6dc8860f Uppity: expect SSH1_CMSG_EXIT_CONFIRMATION.
  eec6666f cmdgen: fix double-free on exit.
  20930e7d Add tests of auxiliary encryption functions.
  986508a5 Merge the ssh1_cipher type into ssh2_cipher.
  07db7f89 Move all the auxiliary cipher functions into a new module.
  c6a8731b Add a consistency test for every ssh_cipheralg.
  acdcf2bf Complete rewrite of sshdes.c.

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:           2019-01-18 19:47:24

commit bf743bf85c6e7222358d8941359ea937782a595a
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=bf743bf85c6e7222358d8941359ea937782a595a;hp=53747ad3ab6194ebd54958a4ca0abcf73a457466
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 18 19:14:27 2019 +0000

    Uppity: properly support _POSIX_VDISABLE in tty modes.
    
    The SSH wire protocol for tty modes corresponding to control
    characters (e.g. configuring what Ctrl-Foo you can press to generate
    SIGINT or SIGQUIT) specifies (RFC 4254 section 8, under VINTR, saying
    'similarly for the other characters') that you should send the value
    255 on the wire if you want _no_ character code to map to the action
    in question.
    
    But in the <termios.h> API, that's indicated by setting the
    appropriate field of 'struct termios' to _POSIX_VDISABLE, which is a
    platform-dependent value and varies between (at least) Linux and *BSD.
    
    On the client side, Unix Plink has always known this: when it copies
    the local termios settings into a struct ssh_ttymodes to be sent on
    the wire, it checks for _POSIX_VDISABLE and replaces it with 255. But
    uxpty.c, mapping ssh_ttymodes back to termios for Uppity's pty
    sessions, wasn't making the reverse transformation.

 unix/uxpty.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

commit 6dc8860f8ace89adc317f385b028e974e853deda
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=6dc8860f8ace89adc317f385b028e974e853deda;hp=bf743bf85c6e7222358d8941359ea937782a595a
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 18 19:14:41 2019 +0000

    Uppity: expect SSH1_CMSG_EXIT_CONFIRMATION.
    
    I've only just noticed that the server-side SSH-1 connection layer had
    no handler for that message, so when an SSH-1 connection terminates in
    the normal way, Uppity's event log reports 'Unexpected packet
    received, type 33 (SSH1_CMSG_EXIT_CONFIRMATION)', which is wrong in
    that it _should_ be expected!

 ssh1connection-server.c | 11 +++++++++++
 ssh1connection.h        |  1 +
 2 files changed, 12 insertions(+)

commit eec6666ff93488405cf2c6f1db86e271dd51648e
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=eec6666ff93488405cf2c6f1db86e271dd51648e;hp=6dc8860f8ace89adc317f385b028e974e853deda
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Jan 17 18:26:24 2019 +0000

    cmdgen: fix double-free on exit.
    
    Freeing ssh1key->comment before calling freersakey() on the whole of
    ssh1key is redundant, and worse, because we also didn't null out the
    freed pointer, causes a double-free.

 cmdgen.c | 1 -
 1 file changed, 1 deletion(-)

commit 20930e7d0c379482fedf32d3fe3b60363d26a3d1
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=20930e7d0c379482fedf32d3fe3b60363d26a3d1;hp=eec6666ff93488405cf2c6f1db86e271dd51648e
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 18 06:39:35 2019 +0000

    Add tests of auxiliary encryption functions.
    
    All the things like des_encrypt_xdmauth and aes256_encrypt_pubkey are
    at risk of changing their behaviour if I rewrite the underlying code,
    so even if I don't have any externally verified test cases, I should
    still have _something_ to keep me confident that they work the same
    way today that they worked yesterday.

 test/cryptsuite.py | 40 ++++++++++++++++++++++++++
 testcrypt.c        | 82 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 testcrypt.h        |  6 ++++
 3 files changed, 128 insertions(+)

commit 986508a5700e6d13de67d4ed99086b4b3d7ab4f5
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=986508a5700e6d13de67d4ed99086b4b3d7ab4f5;hp=20930e7d0c379482fedf32d3fe3b60363d26a3d1
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Jan 17 18:06:08 2019 +0000

    Merge the ssh1_cipher type into ssh2_cipher.
    
    The aim of this reorganisation is to make it easier to test all the
    ciphers in PuTTY in a uniform way. It was inconvenient that there were
    two separate vtable systems for the ciphers used in SSH-1 and SSH-2
    with different functionality.
    
    Now there's only one type, called ssh_cipher. But really it's the old
    ssh2_cipher, just renamed: I haven't made any changes to the API on
    the SSH-2 side. Instead, I've removed ssh1_cipher completely, and
    adapted the SSH-1 BPP to use the SSH-2 style API.
    
    (The relevant differences are that ssh1_cipher encapsulated both the
    sending and receiving directions in one object - so now ssh1bpp has to
    make a separate cipher instance per direction - and that ssh1_cipher
    automatically initialised the IV to all zeroes, which ssh1bpp now has
    to do by hand.)
    
    The previous ssh1_cipher vtable for single-DES has been removed
    completely, because when converted into the new API it became
    identical to the SSH-2 single-DES vtable; so now there's just one
    vtable for DES-CBC which works in both protocols. The other two SSH-1
    ciphers each had to stay separate, because 3DES is completely
    different between SSH-1 and SSH-2 (three layers of CBC structure
    versus one), and Blowfish varies in endianness and key length between
    the two.
    
    (Actually, while I'm here, I've only just noticed that the SSH-1
    Blowfish cipher mis-describes itself in log messages as Blowfish-128.
    In fact it passes the whole of the input key buffer, which has length
    SSH1_SESSION_KEY_LENGTH == 32 bytes == 256 bits. So it's actually
    Blowfish-256, and has been all along!)

 defs.h             |   6 +-
 import.c           |  34 +++++------
 ssh.h              | 125 +++++++++++++++++-----------------------
 ssh1bpp.c          |  35 +++++++-----
 ssh1login-server.c |   6 +-
 ssh1login.c        |   6 +-
 ssh2bpp.c          |  71 ++++++++++++-----------
 ssh2transport.c    |   6 +-
 ssh2transport.h    |   4 +-
 sshaes.c           | 164 ++++++++++++++++++++++++++---------------------------
 ssharcf.c          |  18 +++---
 sshblowf.c         | 123 ++++++++++++++++------------------------
 sshbpp.h           |   6 +-
 sshccp.c           |  26 ++++-----
 sshdes.c           | 157 +++++++++++++++++++-------------------------------
 sshmd5.c           |   3 +-
 sshsh256.c         |   3 +-
 sshsha.c           |   3 +-
 test/cryptsuite.py |  68 +++++++++++-----------
 test/testcrypt.py  |   2 +-
 testcrypt.c        | 160 +++++++++++++++++----------------------------------
 testcrypt.h        |  30 ++++------
 22 files changed, 455 insertions(+), 601 deletions(-)

commit 07db7f89b29f1fea49fc0cc0e7b60b9f4d3e3ad1
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=07db7f89b29f1fea49fc0cc0e7b60b9f4d3e3ad1;hp=986508a5700e6d13de67d4ed99086b4b3d7ab4f5
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 18 06:51:12 2019 +0000

    Move all the auxiliary cipher functions into a new module.
    
    All those functions like aes256_encrypt_pubkey and des_decrypt_xdmauth
    previously lived in the same source files as the ciphers they were
    based on, and provided an alternative API to the internals of that
    cipher's implementation. But there was no _need_ for them to have that
    privileged access to the internals, because they didn't do anything
    you couldn't access through the standard API. It was just a historical
    oddity with no real benefit, whose main effect is to make refactoring
    painful.
    
    So now all of those functions live in a new file sshauxcrypt.c, and
    they all work through the same vtable system as all other cipher
    clients, by making an instance of the right cipher and configuring it
    in the appropriate way. This should make them completely independent
    of any internal changes to the cipher implementations they're based
    on.

 Recipe        |   9 ++--
 sshaes.c      |  27 -----------
 sshauxcrypt.c | 152 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 sshdes.c      | 106 ----------------------------------------
 4 files changed, 157 insertions(+), 137 deletions(-)

commit c6a8731b45a8fc6185216e813f7c3c2efb722768
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=c6a8731b45a8fc6185216e813f7c3c2efb722768;hp=07db7f89b29f1fea49fc0cc0e7b60b9f4d3e3ad1
Author: Simon Tatham <anakin at pobox.com>
Date:   Fri Jan 18 07:23:01 2019 +0000

    Add a consistency test for every ssh_cipheralg.
    
    Like the recently added tests for the auxiliary encryption functions,
    this new set of tests is not derived from any external source: the
    expected results are simply whatever the current PuTTY code delivers
    _now_ for the given operation. The aim is to protect me against
    breakage during refactoring or rewrites.

 test/cryptsuite.py | 83 ++++++++++++++++++++++++++++++++++++++++++++++++------
 1 file changed, 75 insertions(+), 8 deletions(-)

commit acdcf2bfaa2946f607749343c42090caf6515655
web diff https://git.tartarus.org/?p=simon/putty.git;a=commitdiff;h=acdcf2bfaa2946f607749343c42090caf6515655;hp=c6a8731b45a8fc6185216e813f7c3c2efb722768
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Jan 17 18:08:19 2019 +0000

    Complete rewrite of sshdes.c.
    
    DES was the next target in my ongoing programme of trying to make all
    our crypto code constant-time. Unfortunately, DES is very hard to make
    constant-time and still have any kind of performance: my early timing
    tests suggest that the implementation I have here is about 4.5 times
    slower than the implementation it's replacing. That's about the same
    factor as the new AES code when it's not in parallel mode and not
    superseded by hardware acceleration - but of course the difference is
    that AES usually _is_ superseded by HW acceleration or (failing that)
    in parallel mode. This DES implementation doesn't parallelise, and
    there's no hardware alternative, so DES is going to be this slow all
    the time, unless someone sends me code that does it better.
    
    But hopefully that isn't too big a problem. The main use for DES these
    days is legacy devices whose SSH servers haven't been updated to speak
    anything more modern, so with any luck those devices will also be old
    and slow enough that _their_ end will be the bottleneck in connection
    speed!

 sshdes.c       | 1718 ++++++++++++++++++++++++++++----------------------------
 test/desref.py |  197 +++++++
 2 files changed, 1060 insertions(+), 855 deletions(-)



More information about the tartarus-commits mailing list