lp:~vcs-imports/putty/master

Created by Colin Watson and last modified
Get this branch:
bzr branch lp:~vcs-imports/putty/master

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
VCS imports
Project:
PuTTY
Status:
Development

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://git.tartarus.org/simon/putty.git.

The next import is scheduled to run .

Last successful import was .

Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-14 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-13 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-12 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-12 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-17 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-17 and finished taking 15 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-17 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-16 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-16 and finished taking 10 seconds — see the log

Recent revisions

6278. By Simon Tatham

Remove a redundant file in utils.

At some point while setting up the utils subdirectory, I apparently
only got half way through renaming miscucs.c to dup_mb_to_wc.c: I
created the new copy of the file, but I didn't delete the old one, I
didn't mention it in utils/CMakeLists.txt, and I didn't change the
comment at the top.

Now done all three, so we now have just one copy of this utility
module.

6277. By Simon Tatham

Remove a redundant #include.

ptrlen.c doesn't have anything to do with SSH, so it doesn't need
ssh.h.

6276. By Simon Tatham

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

6275. By Simon Tatham

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'.

6274. By Simon Tatham

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.

6273. By Simon Tatham

testcrypt-funcs.h: remove extra parens round argument lists.

They were there to work around that annoying feature of VS's
preprocessor when it expands __VA_ARGS__ into the argument list of
another macro. But I've just thought of a workaround that I can apply
in testcrypt.c itself, so that those parens don't have to appear in
every function definition in the header file.

The trick is, instead of writing

    destination_macro(__VA_ARGS__)

you instead write

    JUXTAPOSE(destination_macro, (__VA_ARGS__))

where JUXTAPOSE is defined to be a macro that simply expands its two
arguments next to each other:

    #define JUXTAPOSE(first, second) first second

This works because the arguments to JUXTAPOSE get macro-expanded
_before_ passing them to JUXTAPOSE itself - the same reason that the
standard tricks with STR_INNER and CAT_INNER work (as seen in defs.h
here). So this defuses the magic behaviour of commas expanded from
__VA_ARGS__, and causes the destination macro to get all its arguments
in the expected places again.

6272. By Simon Tatham

Withdraw support for SHA-512-256 in HTTP Digest.

I was dubious about it to begin with, when I found that RFC 7616's
example seemed to be treating it as a 256-bit truncation of SHA-512,
and not the thing FIPS 180-4 section 6.7 specifies as "SHA-512/256"
(which also changes the initial hash state). Having failed to get a
clarifying response from the RFC authors, I had the idea this morning
of testing other HTTP clients to see what _they_ thought that hash
function meant, and then at least I could go with an existing
in-practice consensus.

There is no in-practice consensus. Firefox doesn't support that
algorithm at all (but they do support SHA-256); wget doesn't support
anything that RFC 7616 added to the original RFC 2617. But the prize
for weirdness goes to curl, which does accept the name "SHA-512-256"
and ... treats it as an alias for SHA-256!

So I think the situation among real clients is too confusing to even
try to work with, and I'm going to stop adding to it. PuTTY will
follow Firefox's policy: if a proxy server asks for SHA-256 digests
we'll happily provide them, but if they ask for SHA-512-256 we'll
refuse on the grounds that it's not clear enough what it means.

6271. By Simon Tatham

Merge be_*.c into one ifdef-controlled module.

This commit replaces all those fiddly little linking modules
(be_all.c, be_none.c, be_ssh.c etc) with a single source file
controlled by ifdefs, and introduces a function be_list() in
setup.cmake that makes it easy to compile a version of it appropriate
to each application.

This is a net reduction in code according to 'git diff --stat', even
though I've introduced more comments. It also gets rid of another pile
of annoying little source files in the top-level directory that didn't
deserve to take up so much room in 'ls'.

More concretely, doing this has some maintenance advantages.
Centralisation means less to maintain (e.g. n_ui_backends is worked
out once in a way that makes sense everywhere), and also, 'appname'
can now be reliably set per program. Previously, some programs got the
wrong appname due to sharing the same linking module (e.g. Plink had
appname="PuTTY"), which was a latent bug that would have manifested if
I'd wanted to reuse the same string in another context.

One thing I've changed in this rework is that Windows pterm no longer
has the ConPTY backend in its backends[]: it now has an empty one. The
special be_conpty.c module shouldn't really have been there in the
first place: it was used in the very earliest uncommitted drafts of
the ConPTY work, where I was using another method of selecting that
backend, but now that Windows pterm has a dedicated
backend_vt_from_conf() that refers to conpty_backend by name, it has
no need to live in backends[] at all, just as it doesn't have to in
Unix pterm.

6270. By Simon Tatham

Move STR() and CAT() into defs.h.

I'm actually quite surprised there was only _one_ copy of each of
these standard macros in the code base, given my general habit of
casually redefining them anywhere I need them! But each one was in a
silly place. Moved them up to the top level where they're available
globally.

6269. By Simon Tatham

Move some more files into subdirectories.

While I'm in the mood for cleaning up the top-level directory here:
all the 'nostuff.c' files have moved into a new 'stubs' directory, and
I broke up be_misc.c into smaller modules that can live in 'utils'.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers