Mark Wooding pointed out that my comment in make1305.py was completely
wrong, and that the stated strategy for reducing a value mod 2^130-5
would not in fact completely reduce all inputs in the range - for the
most obvious reason, namely that the numbers between 2^130-5 and 2^130
would never have anything subtracted at all.
Implemented a replacement strategy which my tests suggest will do the
right thing for all numbers in the expected range that are anywhere
near an integer multiple of the modulus.
It now expects its standard input to be connected to the same PuTTY
its standard output is talking to, i.e. expects to be invoked as a
proxy command. It conducts the same sample key exchange as it used to,
but now reads the SSH greeting and first couple of packets back from
PuTTY and minimally checks that they're something like what it was
expecting.
(In the process, I've also fixed a mistake in the Python message code
enumeration, which caused one of those expect() calls to fail.)
As I mentioned in the previous commit, I'm going to want PuTTY to be
able to run sensibly when compiled with 64-bit Visual Studio,
including handling bignums in 64-bit chunks for speed. Unfortunately,
64-bit VS does not provide any type we can use as BignumDblInt in that
situation (unlike 64-bit gcc and clang, which give us __uint128_t).
The only facilities it provides are compiler intrinsics to access an
add-with-carry operation and a 64x64->128 multiplication (the latter
delivering its product in two separate 64-bit output chunks).
Hence, here's a substantial rework of the bignum code to make it
implement everything in terms of _those_ primitives, rather than
depending throughout on having BignumDblInt available to use ad-hoc.
BignumDblInt does still exist, for the moment, but now it's an
internal implementation detail of sshbn.h, only declared inside a new
set of macros implementing arithmetic primitives, and not accessible
to any code outside sshbn.h (which confirms that I really did catch
all uses of it and remove them).
The resulting code is surprisingly nice-looking, actually. You'd
expect more hassle and roundabout circumlocutions when you drop down
to using a more basic set of primitive operations, but actually, in
many cases it's turned out shorter to write things in terms of the new
BignumADC and BignumMUL macros - because almost all my uses of
BignumDblInt were implementing those operations anyway, taking several
lines at a time, and now they can do each thing in just one line.
The biggest headache was Poly1305: I wasn't able to find any sensible
way to adapt the existing Python script that generates the various
per-int-size implementations of arithmetic mod 2^130-5, and so I had
to rewrite it from scratch instead, with nothing in common with the
old version beyond a handful of comments. But even that seems to have
worked out nicely: the new version has much more legible descriptions
of the high-level algorithms, by virtue of having a 'Multiprecision'
type which wraps up the division into words, and yet Multiprecision's
range analysis allows it to automatically drop out special cases such
as multiplication by 5 being much easier than multiplication by
another multi-word integer.
If a PuTTY SSH packet log has gone through line-wrapping at 72
columns, destroying the long lines of the packet hex dumps, then this
script will reconstitute it as best it can, by reconstructing the
ASCII section at the end of the dump from the (hopefully) undamaged
hex part, and using that to spot wrapped lines and remove the
subsequent debris.
Rather than doing arithmetic mod 2^130-5 using the general-purpose
Bignum library, which requires lots of mallocs and frees per operation
and also uses a general-purpose divide routine for each modular
reduction, we now have some dedicated routines in sshccp.c to do
arithmetic mod 2^130-5 in a more efficient way, and hopefully also
with data-independent performance.
Because PuTTY's target platforms don't all use the same size of bignum
component, I've arranged to auto-generate the arithmetic functions
using a Python script living in the 'contrib' directory. As and when
we need to support an extra BignumInt size, that script should still
be around to re-run with different arguments.
Installing this systemwide as the Windows text selection cursor is a
workaround for 'black-pointer'. It's a white I-beam with a one-pixel
black outline around it, so it should be visible on any background
colour. (I suppose that a backdrop of tightly packed I-beams looking
just like it might successfully hide it, but that's unlikely :-)
I constructed this some years ago for personal use; I needed it again
this week and had to go and recover it from a backup of a defunct
system, which made me think I really ought to check it in somewhere,
and this 'contrib' directory seems like the ideal place.
encodelib.py is a Python library which implements some handy SSH-2
encoding primitives; samplekex.py uses that to fabricate the start of
an SSH connection, up to the point where key exchange totally fails
its crypto.
The idea is that you adapt samplekex.py to construct initial-kex
sequences with particular properties, in order to test robustness and
security fixes that affect the initial-kex sequence. For example, I
used an adaptation of this to test the Diffie-Hellman range check
that's just gone into 0.64.
Bare string exceptions aren't supported any more.
Patch by Will Aoki, plus a backward compatibility tweak from Colin Watson.
Seen working with Python 2.4.3 and 2.7.6.
This provides support for ECDSA public keys, for both hosts and users,
and also ECDH key exchange. Supported curves are currently just the
three NIST curves required by RFC 5656.
I've shifted away from using the SVN revision number as a monotonic
version identifier (replacing it in the Windows version resource with
a count of days since an arbitrary epoch), and I've removed all uses
of SVN keyword expansion (replacing them with version information
written out by Buildscr).
While I'm at it, I've done a major rewrite of the affected code which
centralises all the computation of the assorted version numbers and
strings into Buildscr, so that they're all more or less alongside each
other rather than scattered across multiple source files.
I've also retired the MD5-based manifest file system. A long time ago,
it seemed like a good idea to arrange that binaries of PuTTY would
automatically cease to identify themselves as a particular upstream
version number if any changes were made to the source code, so that if
someone made a local tweak and distributed the result then I wouldn't
get blamed for the results. Since then I've decided the whole idea is
more trouble than it's worth, so now distribution tarballs will have
version information baked in and people can just cope with that.
[originally from svn r10262]
It looks as if it's never worked at all: it had a spurious second
printf, it completely forgot to allow for the uint32 type code that
SSH2_MSG_CHANNEL_DATA doesn't have, it accessed the channel state's
sequence number fields in a way that made no sense and didn't match
the rest of the program, *and* it misinvoked the file opening API. I
must have never had an occasion to test it.
[originally from svn r10037]
Previously it would throw a bunch of Perl undefined-variable-usage
warnings; now it cleanly detects the problem, dumps as much of the
message as it still reasonably can, and doesn't update any channel
states.
[originally from svn r10036]
doesn't have TIOCSCTTY, so my attempt to set the ctty of the child
process isn't doing anything, and only works by chance when you run
bash because bash does the thing that _will_ set the ctty, namely
opening the terminal file again without O_NOCTTY. So now we do that
too.
[originally from svn r9638]
In each case, want_reply was being treated as true even when it wasn't,
because it got decoded into "yes"/"no", both of which are true in
Perl.
[originally from svn r9617]
unconditionally set the telnet state to SEENCR regardless of whether
we have actually seen a CR, and as a result sending a NUL through
PuTTY (via Ctrl-Space or whatever) does not work. Must have arisen
through some kind of really weird cut-and-paste error!
[originally from svn r9545]
interpretation with some analysis done on it. The script will do its
own tracking of the set of open channels and their states, and its
output is in a one-line-per-packet format such that every distinct
channel has a unique identifier in it which should make it easy to
grep out all lines relating to that channel. The script also matches
up {CHANNEL,REQUEST}_{SUCCESS,FAILURE} to the requests that caused
them, by tracking a queue of requests in each direction per channel
and for global requests. Command-line options permit generating a
final dump of all channels ever known to the script and their various
ids and final state, and also dumping out the data transferred over
each channel in each direction.
Output is not complete, in the sense that some parameters in some
messages (e.g. pixel sizes in window-size specifications) are
deliberately omitted due to being boring, and the entire contents of
some messages (e.g. KEXINIT) are omitted because I haven't yet seen
any purpose in decoding them. Filling them in might be a useful thing,
although I'm inclined to think that the default should still be to
show only the potentially interesting stuff (e.g. still not pixel
sizes!) and enable the rest using a -v option.
Hopefully this should do a lot of the legwork in debugging issues in
which a channel mysteriously remains partially open and prevents PuTTY
closing.
[originally from svn r9457]
discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol
version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com
implementations in this scheme). <http://www.snailbook.com/terms.html>
[originally from svn r5480]
