| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369 | 
							- /*
 
-  * 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;
 
-     { // WINSCP
 
-     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;
 
-     } // WINSCP
 
- }
 
- static void BinarySink_put_int2octets(BinarySink *bs, mp_int *x, RFC6979 *s)
 
- {
 
-     mp_int *x_mod_q = mp_mod(x, s->q);
 
-     size_t i; // WINSCP
 
-     for (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. */
 
-     { // WINSCP
 
-     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;
 
-     } // WINSCP
 
- }
 
- 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 */
 
-     size_t i; // WINSCP
 
-     for (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);
 
-     { // WINSCP
 
-     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;
 
-     } // WINSCP
 
- }
 
- 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);
 
-     { // WINSCP
 
-     RFC6979Result result;
 
-     while (true) {
 
-         result = rfc6979_attempt(s);
 
-         if (result.ok)
 
-             break;
 
-         else
 
-             mp_free(result.k);
 
-     }
 
-     rfc6979_free(s);
 
-     return result.k;
 
-     } // WINSCP
 
- }
 
 
  |