PuTTY 0.81

Source commit: 35dc31e2b42102abff4636642858c21ea74b8791

source/putty/crypto/dsa.c

@@ -340,117 +340,6 @@ static int dsa_pubkey_bits(const ssh_keyalg *self, ptrlen pub)
     return ret;
 }
 
-mp_int *dsa_gen_k(const char *id_string, mp_int *modulus,
-                  mp_int *private_key,
-                  unsigned char *digest, int digest_len)
-{
-    /*
-     * The basic DSA signing algorithm is:
-     *
-     *  - invent a random k between 1 and q-1 (exclusive).
-     *  - Compute r = (g^k mod p) mod q.
-     *  - Compute s = k^-1 * (hash + x*r) mod q.
-     *
-     * This has the dangerous properties that:
-     *
-     *  - if an attacker in possession of the public key _and_ the
-     *    signature (for example, the host you just authenticated
-     *    to) can guess your k, he can reverse the computation of s
-     *    and work out x = r^-1 * (s*k - hash) mod q. That is, he
-     *    can deduce the private half of your key, and masquerade
-     *    as you for as long as the key is still valid.
-     *
-     *  - since r is a function purely of k and the public key, if
-     *    the attacker only has a _range of possibilities_ for k
-     *    it's easy for him to work through them all and check each
-     *    one against r; he'll never be unsure of whether he's got
-     *    the right one.
-     *
-     *  - if you ever sign two different hashes with the same k, it
-     *    will be immediately obvious because the two signatures
-     *    will have the same r, and moreover an attacker in
-     *    possession of both signatures (and the public key of
-     *    course) can compute k = (hash1-hash2) * (s1-s2)^-1 mod q,
-     *    and from there deduce x as before.
-     *
-     *  - the Bleichenbacher attack on DSA makes use of methods of
-     *    generating k which are significantly non-uniformly
-     *    distributed; in particular, generating a 160-bit random
-     *    number and reducing it mod q is right out.
-     *
-     * For this reason we must be pretty careful about how we
-     * generate our k. Since this code runs on Windows, with no
-     * particularly good system entropy sources, we can't trust our
-     * RNG itself to produce properly unpredictable data. Hence, we
-     * use a totally different scheme instead.
-     *
-     * What we do is to take a SHA-512 (_big_) hash of the private
-     * key x, and then feed this into another SHA-512 hash that
-     * also includes the message hash being signed. That is:
-     *
-     *   proto_k = SHA512 ( SHA512(x) || SHA160(message) )
-     *
-     * This number is 512 bits long, so reducing it mod q won't be
-     * noticeably non-uniform. So
-     *
-     *   k = proto_k mod q
-     *
-     * This has the interesting property that it's _deterministic_:
-     * signing the same hash twice with the same key yields the
-     * same signature.
-     *
-     * Despite this determinism, it's still not predictable to an
-     * attacker, because in order to repeat the SHA-512
-     * construction that created it, the attacker would have to
-     * know the private key value x - and by assumption he doesn't,
-     * because if he knew that he wouldn't be attacking k!
-     *
-     * (This trick doesn't, _per se_, protect against reuse of k.
-     * Reuse of k is left to chance; all it does is prevent
-     * _excessively high_ chances of reuse of k due to entropy
-     * problems.)
-     *
-     * Thanks to Colin Plumb for the general idea of using x to
-     * ensure k is hard to guess, and to the Cambridge University
-     * Computer Security Group for helping to argue out all the
-     * fine details.
-     */
-    ssh_hash *h;
-    unsigned char digest512[64];
-
-    /*
-     * Hash some identifying text plus x.
-     */
-    h = ssh_hash_new(&ssh_sha512);
-    put_asciz(h, id_string);
-    put_mp_ssh2(h, private_key);
-    ssh_hash_digest(h, digest512);
-
-    /*
-     * Now hash that digest plus the message hash.
-     */
-    ssh_hash_reset(h);
-    put_data(h, digest512, sizeof(digest512));
-    put_data(h, digest, digest_len);
-    ssh_hash_final(h, digest512);
-
-    /*
-     * Now convert the result into a bignum, and coerce it to the
-     * range [2,q), which we do by reducing it mod q-2 and adding 2.
-     */
-    mp_int *modminus2 = mp_copy(modulus);
-    mp_sub_integer_into(modminus2, modminus2, 2);
-    mp_int *proto_k = mp_from_bytes_be(make_ptrlen(digest512, 64));
-    mp_int *k = mp_mod(proto_k, modminus2);
-    mp_free(proto_k);
-    mp_free(modminus2);
-    mp_add_integer_into(k, k, 2);
-
-    smemclr(digest512, sizeof(digest512));
-
-    return k;
-}
-
 static void dsa_sign(ssh_key *key, ptrlen data, unsigned flags, BinarySink *bs)
 {
     struct dsa_key *dsa = container_of(key, struct dsa_key, sshk);
@@ -459,8 +348,9 @@ static void dsa_sign(ssh_key *key, ptrlen data, unsigned flags, BinarySink *bs)
 
     hash_simple(&ssh_sha1, data, digest);
 
-    mp_int *k = dsa_gen_k("DSA deterministic k generator", dsa->q, dsa->x,
-                          digest, sizeof(digest));
+    /* Generate any valid exponent k, using the RFC 6979 deterministic
+     * procedure. */
+    mp_int *k = rfc6979(&ssh_sha1, dsa->q, dsa->x, data);
     mp_int *kinv = mp_invert(k, dsa->q);       /* k^-1 mod q */
 
     /*

source/putty/crypto/ecc-ssh.c

@@ -1126,16 +1126,10 @@ static void ecdsa_sign(ssh_key *key, ptrlen data,
 
     mp_int *z = ecdsa_signing_exponent_from_data(ek->curve, extra, data);
 
-    /* Generate k between 1 and curve->n, using the same deterministic
-     * k generation system we use for conventional DSA. */
-    mp_int *k;
-    {
-        unsigned char digest[20];
-        hash_simple(&ssh_sha1, data, digest);
-        k = dsa_gen_k(
-            "ECDSA deterministic k generator", ek->curve->w.G_order,
-            ek->privateKey, digest, sizeof(digest));
-    }
+    /* Generate any valid exponent k, using the RFC 6979 deterministic
+     * procedure. */
+    mp_int *k = rfc6979(
+        extra->hash, ek->curve->w.G_order, ek->privateKey, data);
 
     WeierstrassPoint *kG = ecc_weierstrass_multiply(ek->curve->w.G, k);
     mp_int *x;

source/putty/crypto/hmac.c

@@ -18,9 +18,10 @@ struct hmac_extra {
     const char *suffix, *annotation;
 };
 
-static ssh2_mac *hmac_new(const ssh2_macalg *alg, ssh_cipher *cipher)
+/* Most of hmac_new(). Takes the actual 'struct hmac' as a parameter,
+ * because sometimes it will have been allocated in a special way. */
+static ssh2_mac *hmac_new_inner(struct hmac *ctx, const ssh2_macalg *alg)
 {
-    struct hmac *ctx = snew(struct hmac);
     const struct hmac_extra *extra = (const struct hmac_extra *)alg->extra;
 
     ctx->h_outer = ssh_hash_new(extra->hashalg_base);
@@ -64,6 +65,11 @@ static ssh2_mac *hmac_new(const ssh2_macalg *alg, ssh_cipher *cipher)
     return &ctx->mac;
 }
 
+static ssh2_mac *hmac_new(const ssh2_macalg *alg, ssh_cipher *cipher)
+{
+    return hmac_new_inner(snew(struct hmac), alg); /* cipher isn't needed */
+}
+
 static void hmac_free(ssh2_mac *mac)
 {
     struct hmac *ctx = container_of(mac, struct hmac, mac);
@@ -277,3 +283,38 @@ const ssh2_macalg ssh_hmac_sha1_96_buggy = {
     .keylen = 16,
     .extra = &ssh_hmac_sha1_96_buggy_extra,
 };
+
+ssh2_mac *hmac_new_from_hash(const ssh_hashalg *hash)
+{
+    /*
+     * Construct a custom ssh2_macalg, derived directly from the
+     * provided hash vtable. It's included in the same memory
+     * allocation as the struct hmac, so that it all gets freed
+     * together.
+     */
+
+    struct alloc {
+        struct hmac hmac;
+        ssh2_macalg alg;
+        struct hmac_extra extra;
+    };
+
+    struct alloc *alloc = snew(struct alloc);
+    alloc->alg.new = hmac_new;
+    alloc->alg.free = hmac_free;
+    alloc->alg.setkey = hmac_key;
+    alloc->alg.start = hmac_start;
+    alloc->alg.genresult = hmac_genresult;
+    alloc->alg.next_message = nullmac_next_message;
+    alloc->alg.text_name = hmac_text_name;
+    alloc->alg.name = NULL;
+    alloc->alg.etm_name = NULL;
+    alloc->alg.len = hash->hlen;
+    alloc->alg.keylen = hash->hlen;
+    alloc->alg.extra = &alloc->extra;
+    alloc->extra.hashalg_base = hash;
+    alloc->extra.suffix = "";
+    alloc->extra.annotation = NULL;
+
+    return hmac_new_inner(&alloc->hmac, &alloc->alg);
+}

source/putty/crypto/rfc6979.c

@@ -0,0 +1,359 @@
+/*
+ * Code to generate 'nonce' values for DSA signature algorithms, in a
+ * deterministic way.
+ */
+
+#include "ssh.h"
+#include "mpint.h"
+#include "misc.h"
+
+/*
+ * All DSA-type signature systems depend on a nonce - a random number
+ * generated during the signing operation.
+ *
+ * This nonce is a weak point of DSA and needs careful protection,
+ * for multiple reasons:
+ *
+ *  1. If an attacker in possession of your public key and a single
+ *     signature can find out or guess the nonce you used in that
+ *     signature, they can immediately recover your _private key_.
+ *
+ *  2. If you reuse the same nonce in two different signatures, this
+ *     will be instantly obvious to the attacker (one of the two
+ *     values making up the signature will match), and again, they can
+ *     immediately recover the private key as soon as they notice this.
+ *
+ *  3. In at least one system, information about your private key is
+ *     leaked merely by generating nonces with a significant bias.
+ *
+ * Attacks #1 and #2 work across all of integer DSA, NIST-style ECDSA,
+ * and EdDSA. The details vary, but the headline effects are the same.
+ *
+ * So we must be very careful with our nonces. They must be generated
+ * with uniform distribution, but also, they must avoid depending on
+ * any random number generator that has the slightest doubt about its
+ * reliability.
+ *
+ * In particular, PuTTY's policy is that for this purpose we don't
+ * _even_ trust the PRNG we use for other cryptography. This is mostly
+ * a concern because of Windows, where system entropy sources are
+ * limited and we have doubts about their trustworthiness
+ * - even CryptGenRandom. PuTTY compensates as best it can with its
+ * own ongoing entropy collection, and we trust that for session keys,
+ * but revealing the private key that goes with a long-term public key
+ * is a far worse outcome than revealing one SSH session key, and for
+ * keeping your private key safe, we don't think the available Windows
+ * entropy gives us enough confidence.
+ *
+ * A common strategy these days (although <hipster>PuTTY was doing it
+ * before it was cool</hipster>) is to avoid using a PRNG based on
+ * system entropy at all. Instead, you use a deterministic PRNG that
+ * starts from a fixed input seed, and in that input seed you include
+ * the message to be signed and the _private key_.
+ *
+ * Including the private key in the seed is counterintuitive, but does
+ * actually make sense. A deterministic nonce generation strategy must
+ * use _some_ piece of input that the attacker doesn't have, or else
+ * they'd be able to repeat the entire computation and construct the
+ * same nonce you did. And the one thing they don't know is the
+ * private key! So we include that in the seed data (under enough
+ * layers of overcautious hashing to protect it against exposure), and
+ * then they _can't_ repeat the same construction. Moreover, if they
+ * _could_, they'd already know the private key, so they wouldn't need
+ * to perform an attack of this kind at all!
+ *
+ * (This trick doesn't, _per se_, protect against reuse of nonces.
+ * That is left to chance, which is enough, because the space of
+ * nonces is large enough to make it adequately unlikely. But it
+ * avoids escalating the reuse risk due to inadequate entropy.)
+ *
+ * For integer DSA and ECDSA, the system we use for deterministic
+ * generation of k is exactly the one specified in RFC 6979. We
+ * switched to this from the old system that PuTTY used to use before
+ * that RFC came out. The old system had a critical bug: it did not
+ * always generate _enough_ data to get uniform distribution, because
+ * its output was a single SHA-512 hash. We could have fixed that
+ * minimally, by concatenating multiple hashes, but it seemed more
+ * sensible to switch to a system that comes with test vectors.
+ *
+ * One downside of RFC 6979 is that it's based on rejection sampling
+ * (that is, you generate a random number and keep retrying until it's
+ * in range). This makes it play badly with our side-channel test
+ * system, which wants every execution trace of a supposedly
+ * constant-time operation to be the same. To work around this
+ * awkwardness, we break up the algorithm further, into a setup phase
+ * and an 'attempt to generate an output' phase, each of which is
+ * individually constant-time.
+ */
+
+struct RFC6979 {
+    /*
+     * Size of the cyclic group over which we're doing DSA.
+     * Equivalently, the multiplicative order of g (for integer DSA)
+     * or the curve's base point (for ECDSA). For integer DSA this is
+     * also the same thing as the small prime q from the key
+     * parameters.
+     *
+     * This pointer is not owned. Freeing this structure will not free
+     * it, and freeing the pointed-to integer before freeing this
+     * structure will make this structure dangerous to use.
+     */
+    mp_int *q;
+
+    /*
+     * The private key integer, which is always the discrete log of
+     * the public key with respect to the group generator.
+     *
+     * This pointer is not owned. Freeing this structure will not free
+     * it, and freeing the pointed-to integer before freeing this
+     * structure will make this structure dangerous to use.
+     */
+    mp_int *x;
+
+    /*
+     * Cached values derived from q: its length in bits, and in bytes.
+     */
+    size_t qbits, qbytes;
+
+    /*
+     * Reusable hash and MAC objects.
+     */
+    ssh_hash *hash;
+    ssh2_mac *mac;
+
+    /*
+     * Cached value: the output length of the hash.
+     */
+    size_t hlen;
+
+    /*
+     * The byte string V used in the algorithm.
+     */
+    unsigned char V[MAX_HASH_LEN];
+
+    /*
+     * The string T to use during each attempt, and how many
+     * hash-sized blocks to fill it with.
+     */
+    size_t T_nblocks;
+    unsigned char *T;
+};
+
+static mp_int *bits2int(ptrlen b, RFC6979 *s)
+{
+    if (b.len > s->qbytes)
+        b.len = s->qbytes;
+    mp_int *x = mp_from_bytes_be(b);
+
+    /*
+     * Rationale for using mp_rshift_fixed_into and not
+     * mp_rshift_safe_into: the shift count is derived from the
+     * difference between the length of the modulus q, and the length
+     * of the input bit string, i.e. between the _sizes_ of things
+     * involved in the protocol. But the sizes aren't secret. Only the
+     * actual values of integers and bit strings of those sizes are
+     * secret. So it's OK for the shift count to be known to an
+     * attacker - they'd know it anyway just from which DSA algorithm
+     * we were using.
+     */
+    if (b.len * 8 > s->qbits)
+        mp_rshift_fixed_into(x, x, b.len * 8 - s->qbits);
+
+    return x;
+}
+
+static void BinarySink_put_int2octets(BinarySink *bs, mp_int *x, RFC6979 *s)
+{
+    mp_int *x_mod_q = mp_mod(x, s->q);
+    for (size_t i = s->qbytes; i-- > 0 ;)
+        put_byte(bs, mp_get_byte(x_mod_q, i));
+    mp_free(x_mod_q);
+}
+
+static void BinarySink_put_bits2octets(BinarySink *bs, ptrlen b, RFC6979 *s)
+{
+    mp_int *x = bits2int(b, s);
+    BinarySink_put_int2octets(bs, x, s);
+    mp_free(x);
+}
+
+#define put_int2octets(bs, x, s) \
+    BinarySink_put_int2octets(BinarySink_UPCAST(bs), x, s)
+#define put_bits2octets(bs, b, s) \
+    BinarySink_put_bits2octets(BinarySink_UPCAST(bs), b, s)
+
+RFC6979 *rfc6979_new(const ssh_hashalg *hashalg, mp_int *q, mp_int *x)
+{
+    /* Make the state structure. */
+    RFC6979 *s = snew(RFC6979);
+    s->q = q;
+    s->x = x;
+    s->qbits = mp_get_nbits(q);
+    s->qbytes = (s->qbits + 7) >> 3;
+    s->hash = ssh_hash_new(hashalg);
+    s->mac = hmac_new_from_hash(hashalg);
+    s->hlen = hashalg->hlen;
+
+    /* In each attempt, we concatenate enough hash blocks to be
+     * greater than qbits in size. */
+    size_t hbits = 8 * s->hlen;
+    s->T_nblocks = (s->qbits + hbits - 1) / hbits;
+    s->T = snewn(s->T_nblocks * s->hlen, unsigned char);
+
+    return s;
+}
+
+void rfc6979_setup(RFC6979 *s, ptrlen message)
+{
+    unsigned char h1[MAX_HASH_LEN];
+    unsigned char K[MAX_HASH_LEN];
+
+    /* 3.2 (a): hash the message to get h1. */
+    ssh_hash_reset(s->hash);
+    put_datapl(s->hash, message);
+    ssh_hash_digest(s->hash, h1);
+
+    /* 3.2 (b): set V to a sequence of 0x01 bytes the same size as the
+     * hash function's output. */
+    memset(s->V, 1, s->hlen);
+
+    /* 3.2 (c): set the initial HMAC key K to all zeroes, again the
+     * same size as the hash function's output. */
+    memset(K, 0, s->hlen);
+    ssh2_mac_setkey(s->mac, make_ptrlen(K, s->hlen));
+
+    /* 3.2 (d): compute the MAC of V, the private key, and h1, with
+     * key K, making a new key to replace K. */
+    ssh2_mac_start(s->mac);
+    put_data(s->mac, s->V, s->hlen);
+    put_byte(s->mac, 0);
+    put_int2octets(s->mac, s->x, s);
+    put_bits2octets(s->mac, make_ptrlen(h1, s->hlen), s);
+    ssh2_mac_genresult(s->mac, K);
+    ssh2_mac_setkey(s->mac, make_ptrlen(K, s->hlen));
+
+    /* 3.2 (e): replace V with its HMAC using the new K. */
+    ssh2_mac_start(s->mac);
+    put_data(s->mac, s->V, s->hlen);
+    ssh2_mac_genresult(s->mac, s->V);
+
+    /* 3.2 (f): repeat step (d), only using the new K in place of the
+     * initial all-zeroes one, and with the extra byte in the middle
+     * of the MAC preimage being 1 rather than 0. */
+    ssh2_mac_start(s->mac);
+    put_data(s->mac, s->V, s->hlen);
+    put_byte(s->mac, 1);
+    put_int2octets(s->mac, s->x, s);
+    put_bits2octets(s->mac, make_ptrlen(h1, s->hlen), s);
+    ssh2_mac_genresult(s->mac, K);
+    ssh2_mac_setkey(s->mac, make_ptrlen(K, s->hlen));
+
+    /* 3.2 (g): repeat step (e), using the again-replaced K. */
+    ssh2_mac_start(s->mac);
+    put_data(s->mac, s->V, s->hlen);
+    ssh2_mac_genresult(s->mac, s->V);
+
+    smemclr(h1, sizeof(h1));
+    smemclr(K, sizeof(K));
+}
+
+RFC6979Result rfc6979_attempt(RFC6979 *s)
+{
+    RFC6979Result result;
+
+    /* 3.2 (h) 1: set T to the empty string */
+    /* 3.2 (h) 2: make lots of output by concatenating MACs of V */
+    for (size_t i = 0; i < s->T_nblocks; i++) {
+        ssh2_mac_start(s->mac);
+        put_data(s->mac, s->V, s->hlen);
+        ssh2_mac_genresult(s->mac, s->V);
+        memcpy(s->T + i * s->hlen, s->V, s->hlen);
+    }
+
+    /* 3.2 (h) 3: if we have a number in [1, q-1], return it ... */
+    result.k = bits2int(make_ptrlen(s->T, s->T_nblocks * s->hlen), s);
+    result.ok = mp_hs_integer(result.k, 1) & ~mp_cmp_hs(result.k, s->q);
+
+    /*
+     * Perturb K and regenerate V ready for the next attempt.
+     *
+     * We do this unconditionally, whether or not the k we just
+     * generated is acceptable. The time cost isn't large compared to
+     * the public-key operation we're going to do next (not to mention
+     * the larger number of these same operations we've already done),
+     * and it makes side-channel testing easier if this function is
+     * constant-time from beginning to end.
+     *
+     * In other rejection-sampling situations, particularly prime
+     * generation, we're not this careful: it's enough to ensure that
+     * _successful_ attempts run in constant time, Failures can do
+     * whatever they like, on the theory that the only information
+     * they _have_ to potentially expose via side channels is
+     * information that was subsequently thrown away without being
+     * used for anything important. (Hence, for example, it's fine to
+     * have multiple different early-exit paths for failures you
+     * detect at different times.)
+     *
+     * But here, the situation is different. Prime generation attempts
+     * are independent of each other. These are not. All our
+     * iterations round this loop use the _same_ secret data set up by
+     * rfc6979_new(), and also, the perturbation step we're about to
+     * compute will be used by the next iteration if there is one. So
+     * it's absolutely _not_ true that a failed iteration deals
+     * exclusively with data that won't contribute to the eventual
+     * output. Hence, we have to be careful about the failures as well
+     * as the successes.
+     *
+     * (Even so, it would be OK to make successes and failures take
+     * different amounts of time, as long as each of those amounts was
+     * consistent. But it's easier for testing to make them the same.)
+     */
+    ssh2_mac_start(s->mac);
+    put_data(s->mac, s->V, s->hlen);
+    put_byte(s->mac, 0);
+    unsigned char K[MAX_HASH_LEN];
+    ssh2_mac_genresult(s->mac, K);
+    ssh2_mac_setkey(s->mac, make_ptrlen(K, s->hlen));
+    smemclr(K, sizeof(K));
+
+    ssh2_mac_start(s->mac);
+    put_data(s->mac, s->V, s->hlen);
+    ssh2_mac_genresult(s->mac, s->V);
+
+    return result;
+}
+
+void rfc6979_free(RFC6979 *s)
+{
+    /* We don't free s->q or s->x: our caller still owns those. */
+
+    ssh_hash_free(s->hash);
+    ssh2_mac_free(s->mac);
+    smemclr(s->T, s->T_nblocks * s->hlen);
+    sfree(s->T);
+
+    /* Clear the whole structure before freeing. Most fields aren't
+     * sensitive (pointers or well-known length values), but V is, and
+     * it's easier to clear the whole lot than fiddle about
+     * identifying the sensitive fields. */
+    smemclr(s, sizeof(*s));
+
+    sfree(s);
+}
+
+mp_int *rfc6979(
+    const ssh_hashalg *hashalg, mp_int *q, mp_int *x, ptrlen message)
+{
+    RFC6979 *s = rfc6979_new(hashalg, q, x);
+    rfc6979_setup(s, message);
+    RFC6979Result result;
+    while (true) {
+        result = rfc6979_attempt(s);
+        if (result.ok)
+            break;
+        else
+            mp_free(result.k);
+    }
+    rfc6979_free(s);
+    return result.k;
+}

source/putty/defs.h

@@ -177,6 +177,8 @@ typedef struct ecdh_key ecdh_key;
 typedef struct ecdh_keyalg ecdh_keyalg;
 typedef struct NTRUKeyPair NTRUKeyPair;
 typedef struct NTRUEncodeSchedule NTRUEncodeSchedule;
+typedef struct RFC6979 RFC6979;
+typedef struct RFC6979Result RFC6979Result;
 
 typedef struct dlgparam dlgparam;
 typedef struct dlgcontrol dlgcontrol;

source/putty/doc/plink.but

@@ -41,7 +41,7 @@ use Plink:
 
 \c C:\>plink
 \c Plink: command-line connection utility
-\c Release 0.80
+\c Release 0.81
 \c Usage: plink [options] [user@]host [command]
 \c        ("host" can also be a PuTTY saved session name)
 \c Options:

source/putty/doc/pscp.but

@@ -39,7 +39,7 @@ use PSCP:
 
 \c C:\>pscp
 \c PuTTY Secure Copy client
-\c Release 0.80
+\c Release 0.81
 \c Usage: pscp [options] [user@]host:source target
 \c        pscp [options] source [source...] [user@]host:target
 \c        pscp [options] -ls [user@]host:filespec

source/putty/doc/puttydoc.txt

@@ -12,7 +12,7 @@ not described here; and the pterm and command-line puttygen and pageant
 utilities are not described at all. The only Unix-specific documentation
 that currently exists is the man pages.
 
-This manual is copyright 1997-2023 Simon Tatham. All rights reserved. You
+This manual is copyright 1997-2024 Simon Tatham. All rights reserved. You
 may distribute this documentation under the MIT licence. See appendix D for
 the licence text in full.
 
@@ -5530,7 +5530,7 @@ Chapter 5: Using PSCP to transfer files securely
 
          C:\>pscp
          PuTTY Secure Copy client
-         Release 0.80
+         Release 0.81
          Usage: pscp [options] [user@]host:source target
                 pscp [options] source [source...] [user@]host:target
                 pscp [options] -ls [user@]host:filespec
@@ -6452,7 +6452,7 @@ Chapter 7: Using the command-line connection tool Plink
 
          C:\>plink
          Plink: command-line connection utility
-         Release 0.80
+         Release 0.81
          Usage: plink [options] [user@]host [command]
                 ("host" can also be a PuTTY saved session name)
          Options:
@@ -10789,7 +10789,7 @@ Appendix C: PPK file format
 Appendix D: PuTTY Licence
 -------------------------
 
-       PuTTY is copyright 1997-2023 Simon Tatham.
+       PuTTY is copyright 1997-2024 Simon Tatham.
 
        Portions copyright Robert de Bath, Joris van Rantwijk, Delian
        Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry,
@@ -12479,4 +12479,4 @@ H.6.12 PLUGIN_AUTH_FAILURE
        Secure Shell Protocol (SSH)' (better known by its wire id `keyboard-
        interactive').
 
-[PuTTY release 0.80]
+[PuTTY release 0.81]

source/putty/doc/version.but

@@ -1 +1 @@
-\versionid PuTTY release 0.80
+\versionid PuTTY release 0.81

source/putty/ssh.h

@@ -629,11 +629,18 @@ mp_int *ssh_rsakex_decrypt(
     RSAKey *key, const ssh_hashalg *h, ptrlen ciphertext);
 
 /*
- * Helper function for k generation in DSA, reused in ECDSA
+ * System for generating k in DSA and ECDSA.
  */
-mp_int *dsa_gen_k(const char *id_string,
-                  mp_int *modulus, mp_int *private_key,
-                  unsigned char *digest, int digest_len);
+struct RFC6979Result {
+    mp_int *k;
+    unsigned ok;
+};
+RFC6979 *rfc6979_new(const ssh_hashalg *hashalg, mp_int *q, mp_int *x);
+void rfc6979_setup(RFC6979 *s, ptrlen message);
+RFC6979Result rfc6979_attempt(RFC6979 *s);
+void rfc6979_free(RFC6979 *s);
+mp_int *rfc6979(const ssh_hashalg *hashalg, mp_int *modulus,
+                mp_int *private_key, ptrlen message);
 
 struct ssh_cipher {
     const ssh_cipheralg *vt;
@@ -762,6 +769,11 @@ void nullmac_next_message(ssh2_mac *m);
  * string with a given key in the most obvious way. */
 void mac_simple(const ssh2_macalg *alg, ptrlen key, ptrlen data, void *output);
 
+/* Constructor that makes an HMAC object given just a MAC. This object
+ * will have empty 'name' and 'etm_name' fields, so it's not suitable
+ * for use in SSH. It's used as a subroutine in RFC 6979. */
+ssh2_mac *hmac_new_from_hash(const ssh_hashalg *hash);
+
 struct ssh_hash {
     const ssh_hashalg *vt;
     BinarySink_DELEGATE_IMPLEMENTATION;
@@ -1205,6 +1217,7 @@ extern const ssh2_macalg ssh_hmac_sha1_buggy;
 extern const ssh2_macalg ssh_hmac_sha1_96;
 extern const ssh2_macalg ssh_hmac_sha1_96_buggy;
 extern const ssh2_macalg ssh_hmac_sha256;
+extern const ssh2_macalg ssh_hmac_sha384;
 extern const ssh2_macalg ssh_hmac_sha512;
 extern const ssh2_macalg ssh2_poly1305;
 extern const ssh2_macalg ssh2_aesgcm_mac;

source/putty/utils/memory.c

@@ -2,6 +2,12 @@
  * PuTTY's memory allocation wrappers.
  */
 
+#ifdef ALLOCATION_ALIGNMENT
+/* Before we include standard headers, define _ISOC11_SOURCE so that
+ * we get the declaration of aligned_alloc(). */
+#define _ISOC11_SOURCE
+#endif
+
 #include <assert.h>
 #include <stdlib.h>
 #include <limits.h>
@@ -28,6 +34,8 @@ void *safemalloc(size_t factor1, size_t factor2, size_t addend)
     void *p;
 #ifdef MINEFIELD
     p = minefield_c_malloc(size);
+#elif defined ALLOCATION_ALIGNMENT
+    p = aligned_alloc(ALLOCATION_ALIGNMENT, size);
 #else
     p = malloc(size);
 #endif
@@ -52,6 +60,8 @@ void *saferealloc(void *ptr, size_t n, size_t size)
         if (!ptr) {
 #ifdef MINEFIELD
             p = minefield_c_malloc(size);
+#elif defined ALLOCATION_ALIGNMENT
+            p = aligned_alloc(ALLOCATION_ALIGNMENT, size);
 #else
             p = malloc(size);
 #endif

source/putty/version.h

@@ -1,5 +1,5 @@
 /* Generated by automated build script */
-#define RELEASE 0.80
-#define TEXTVER "Release 0.80"
-#define SSHVER "-Release-0.80"
-#define BINARY_VERSION 0,80,0,0
+#define RELEASE 0.81
+#define TEXTVER "Release 0.81"
+#define SSHVER "-Release-0.81"
+#define BINARY_VERSION 0,81,0,0