nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
b26077b1ae
putty-source/crypto/prng.c

288 lines
8.8 KiB
C
Raw Normal View History

Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
/*
Move crypto into its own subdirectory. Similarly to 'utils', I've moved all the stuff in the crypto build-time library into a source directory of its own, and while I'm at it, split up the monolithic sshauxcrypt.c into its various unrelated parts. This is also an opportunity to remove the annoying 'ssh' prefix from the front of the file names, and give several of them less cryptic names.
2021-04-18 12:16:59 +00:00
* PuTTY's cryptographic pseudorandom number generator.
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
*
* This module just defines the PRNG object type and its methods. The
* usual global instance of it is managed by sshrand.c.
*/
#include "putty.h"
#include "ssh.h"
Stop using mp_int in sshprng.c. We keep an internal 128-bit counter that's used as part of the hash preimages. There's no real need to import all the mp_int machinery in order to implement that: we can do it by hand using a small fixed-size array and a trivial use of BignumADC. This is another inter-module dependency that's easy to remove and useful to spinoff programs. This changes the hash preimage calculation in the PRNG, because we're now formatting our 128-bit integer in the fixed-length representation of 16 little-endian bytes instead of as an SSH-2 mpint. This is harmless (perhaps even mildly beneficial, due to the length now not depending on how long the PRNG has been running), but means I have to update the PRNG tests as well.
2020-09-13 07:42:54 +00:00
#include "mpint_i.h"
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
#ifdef PRNG_DIAGNOSTICS
#define prngdebug debug
#else
#define prngdebug(...) ((void)0)
#endif
/*
* This random number generator is based on the 'Fortuna' design by
* Niels Ferguson and Bruce Schneier. The biggest difference is that I
* use SHA-256 in place of a block cipher: the generator side of the
* system works by computing HASH(key || counter) instead of
* ENCRYPT(counter, key).
*
* Rationale: the Fortuna description itself suggests that using
* SHA-256 would be nice but people wouldn't accept it because it's
* too slow - but PuTTY isn't a heavy enough user of random numbers to
* make that a serious worry. In fact even with SHA-256 this generator
* is faster than the one we previously used. Also the Fortuna
* description worries about periodic rekeying to avoid the barely
* detectable pattern of never repeating a cipher block - but with
* SHA-256, even that shouldn't be a worry, because the output
* 'blocks' are twice the size, and also SHA-256 has no guarantee of
* bijectivity, so it surely _could_ be possible to generate the same
* block from two counter values. Thirdly, Fortuna has to have a hash
* function anyway, for reseeding and entropy collection, so reusing
* the same one means it only depends on one underlying primitive and
* can be easily reinstantiated with a larger hash function if you
* decide you'd like to do that on a particular occasion.
*/
#define NCOLLECTORS 32
#define RESEED_DATA_SIZE 64
typedef struct prng_impl prng_impl;
struct prng_impl {
prng Prng;
const ssh_hashalg *hashalg;
/*
* Generation side:
*
* 'generator' is a hash object with the current key preloaded
* into it. The counter-mode generation is achieved by copying
* that hash object, appending the counter value to the copy, and
* calling ssh_hash_final.
*/
ssh_hash *generator;
Stop using mp_int in sshprng.c. We keep an internal 128-bit counter that's used as part of the hash preimages. There's no real need to import all the mp_int machinery in order to implement that: we can do it by hand using a small fixed-size array and a trivial use of BignumADC. This is another inter-module dependency that's easy to remove and useful to spinoff programs. This changes the hash preimage calculation in the PRNG, because we're now formatting our 128-bit integer in the fixed-length representation of 16 little-endian bytes instead of as an SSH-2 mpint. This is harmless (perhaps even mildly beneficial, due to the length now not depending on how long the PRNG has been running), but means I have to update the PRNG tests as well.
2020-09-13 07:42:54 +00:00
BignumInt counter[128 / BIGNUM_INT_BITS];
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
/*
* When re-seeding the generator, you call prng_seed_begin(),
* which sets up a hash object in 'keymaker'. You write your new
* seed data into it (which you can do by calling put_data on the
* PRNG object itself) and then call prng_seed_finish(), which
* finalises this hash and uses the output to set up the new
* generator.
*
* The keymaker hash preimage includes the previous key, so if you
* just want to change keys for the sake of not keeping the same
* one for too long, you don't have to put any extra seed data in
* at all.
*/
ssh_hash *keymaker;
/*
* Collection side:
*
* There are NCOLLECTORS hash objects collecting entropy. Each
* separately numbered entropy source puts its output into those
* hash objects in the order 0,1,0,2,0,1,0,3,0,1,0,2,0,1,0,4,...,
* that is to say, each entropy source has a separate counter
* which is incremented every time that source generates an event,
* and the event data is added to the collector corresponding to
* the index of the lowest set bit in the current counter value.
*
* Whenever collector #0 has at least RESEED_DATA_SIZE bytes (and
* it's not at least 100ms since the last reseed), the PRNG is
* reseeded, with seed data on reseed #n taken from the first j
* collectors, where j is one more than the number of factors of 2
* in n. That is, collector #0 is used in every reseed; #1 in
* every other one, #2 in every fourth, etc.
*
* 'until_reseed' counts the amount of data that still needs to be
* added to collector #0 before a reseed will be triggered.
*/
uint32_t source_counters[NOISE_MAX_SOURCES];
ssh_hash *collectors[NCOLLECTORS];
size_t until_reseed;
uint32_t reseeds;
uint64_t last_reseed_time;
};
static void prng_seed_BinarySink_write(
BinarySink *bs, const void *data, size_t len);
prng *prng_new(const ssh_hashalg *hashalg)
{
prng_impl *pi = snew(prng_impl);
memset(pi, 0, sizeof(prng_impl));
pi->hashalg = hashalg;
pi->keymaker = NULL;
pi->generator = NULL;
Stop using mp_int in sshprng.c. We keep an internal 128-bit counter that's used as part of the hash preimages. There's no real need to import all the mp_int machinery in order to implement that: we can do it by hand using a small fixed-size array and a trivial use of BignumADC. This is another inter-module dependency that's easy to remove and useful to spinoff programs. This changes the hash preimage calculation in the PRNG, because we're now formatting our 128-bit integer in the fixed-length representation of 16 little-endian bytes instead of as an SSH-2 mpint. This is harmless (perhaps even mildly beneficial, due to the length now not depending on how long the PRNG has been running), but means I have to update the PRNG tests as well.
2020-09-13 07:42:54 +00:00
memset(pi->counter, 0, sizeof(pi->counter));
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
for (size_t i = 0; i < NCOLLECTORS; i++)
pi->collectors[i] = ssh_hash_new(pi->hashalg);
pi->until_reseed = 0;
BinarySink_INIT(&pi->Prng, prng_seed_BinarySink_write);
pi->Prng.savesize = pi->hashalg->hlen * 4;
return &pi->Prng;
}
void prng_free(prng *pr)
{
prng_impl *pi = container_of(pr, prng_impl, Prng);
Stop using mp_int in sshprng.c. We keep an internal 128-bit counter that's used as part of the hash preimages. There's no real need to import all the mp_int machinery in order to implement that: we can do it by hand using a small fixed-size array and a trivial use of BignumADC. This is another inter-module dependency that's easy to remove and useful to spinoff programs. This changes the hash preimage calculation in the PRNG, because we're now formatting our 128-bit integer in the fixed-length representation of 16 little-endian bytes instead of as an SSH-2 mpint. This is harmless (perhaps even mildly beneficial, due to the length now not depending on how long the PRNG has been running), but means I have to update the PRNG tests as well.
2020-09-13 07:42:54 +00:00
smemclr(pi->counter, sizeof(pi->counter));
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
for (size_t i = 0; i < NCOLLECTORS; i++)
ssh_hash_free(pi->collectors[i]);
if (pi->generator)
ssh_hash_free(pi->generator);
if (pi->keymaker)
ssh_hash_free(pi->keymaker);
smemclr(pi, sizeof(*pi));
sfree(pi);
}
void prng_seed_begin(prng *pr)
{
prng_impl *pi = container_of(pr, prng_impl, Prng);
assert(!pi->keymaker);
prngdebug("prng: reseed begin\n");
/*
* Make a hash instance that will generate the key for the new one.
*/
if (pi->generator) {
pi->keymaker = pi->generator;
pi->generator = NULL;
} else {
pi->keymaker = ssh_hash_new(pi->hashalg);
}
put_byte(pi->keymaker, 'R');
}
static void prng_seed_BinarySink_write(
BinarySink *bs, const void *data, size_t len)
{
prng *pr = BinarySink_DOWNCAST(bs, prng);
prng_impl *pi = container_of(pr, prng_impl, Prng);
assert(pi->keymaker);
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
prngdebug("prng: got %"SIZEu" bytes of seed\n", len);
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
put_data(pi->keymaker, data, len);
}
void prng_seed_finish(prng *pr)
{
prng_impl *pi = container_of(pr, prng_impl, Prng);
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
unsigned char buf[MAX_HASH_LEN];
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
assert(pi->keymaker);
prngdebug("prng: reseed finish\n");
/*
* Actually generate the key.
*/
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
ssh_hash_final(pi->keymaker, buf);
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
pi->keymaker = NULL;
/*
* Load that key into a fresh hash instance, which will become the
* new generator.
*/
assert(!pi->generator);
pi->generator = ssh_hash_new(pi->hashalg);
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
put_data(pi->generator, buf, pi->hashalg->hlen);
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
pi->until_reseed = RESEED_DATA_SIZE;
pi->last_reseed_time = prng_reseed_time_ms();
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
smemclr(buf, sizeof(buf));
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
}
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
static inline void prng_generate(prng_impl *pi, void *outbuf)
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
{
ssh_hash *h = ssh_hash_copy(pi->generator);
prngdebug("prng_generate\n");
put_byte(h, 'G');
Stop using mp_int in sshprng.c. We keep an internal 128-bit counter that's used as part of the hash preimages. There's no real need to import all the mp_int machinery in order to implement that: we can do it by hand using a small fixed-size array and a trivial use of BignumADC. This is another inter-module dependency that's easy to remove and useful to spinoff programs. This changes the hash preimage calculation in the PRNG, because we're now formatting our 128-bit integer in the fixed-length representation of 16 little-endian bytes instead of as an SSH-2 mpint. This is harmless (perhaps even mildly beneficial, due to the length now not depending on how long the PRNG has been running), but means I have to update the PRNG tests as well.
2020-09-13 07:42:54 +00:00
for (unsigned i = 0; i < 128; i += 8)
put_byte(h, pi->counter[i/BIGNUM_INT_BITS] >> (i%BIGNUM_INT_BITS));
BignumCarry c = 1;
for (unsigned i = 0; i < lenof(pi->counter); i++)
BignumADC(pi->counter[i], c, pi->counter[i], 0, c);
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
ssh_hash_final(h, outbuf);
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
}
void prng_read(prng *pr, void *vout, size_t size)
{
prng_impl *pi = container_of(pr, prng_impl, Prng);
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
unsigned char buf[MAX_HASH_LEN];
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
assert(!pi->keymaker);
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
prngdebug("prng_read %"SIZEu"\n", size);
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
uint8_t *out = (uint8_t *)vout;
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
while (size > 0) {
prng_generate(pi, buf);
size_t to_use = size > pi->hashalg->hlen ? pi->hashalg->hlen : size;
memcpy(out, buf, to_use);
out += to_use;
size -= to_use;
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
}
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
smemclr(buf, sizeof(buf));
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
prng_seed_begin(&pi->Prng);
prng_seed_finish(&pi->Prng);
}
void prng_add_entropy(prng *pr, unsigned source_id, ptrlen data)
{
prng_impl *pi = container_of(pr, prng_impl, Prng);
assert(source_id < NOISE_MAX_SOURCES);
uint32_t counter = ++pi->source_counters[source_id];
size_t index = 0;
while (index+1 < NCOLLECTORS && !(counter & 1)) {
counter >>= 1;
index++;
}
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
prngdebug("prng_add_entropy source=%u size=%"SIZEu" -> collector %zi\n",
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
source_id, data.len, index);
put_datapl(pi->collectors[index], data);
if (index == 0)
pi->until_reseed = (pi->until_reseed < data.len ? 0 :
pi->until_reseed - data.len);
if (pi->until_reseed == 0 &&
prng_reseed_time_ms() - pi->last_reseed_time >= 100) {
prng_seed_begin(&pi->Prng);
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
unsigned char buf[MAX_HASH_LEN];
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
uint32_t reseed_index = ++pi->reseeds;
prngdebug("prng entropy reseed #%"PRIu32"\n", reseed_index);
for (size_t i = 0; i < NCOLLECTORS; i++) {
New wrapper macro for printf("%zu"), for old VS compat. A user reports that Visual Studio 2013 and earlier have printf implementations in their C library that don't support the 'z' modifier to indicate that an integer argument is size_t. The 'I' modifier apparently works in place of it. To avoid littering ifdefs everywhere, I've invented my own inttypes.h style macros to wrap size_t formatting directives, which are defined to %zu and %zx normally, or %Iu and %Ix in old-VS mode. Those are in defs.h, and they're used everywhere that a %z might otherwise get into the Windows build.
2020-01-26 10:59:07 +00:00
prngdebug("emptying collector %"SIZEu"\n", i);
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
ssh_hash_digest(pi->collectors[i], buf);
put_data(&pi->Prng, buf, pi->hashalg->hlen);
Adopt the new hash API functions where they're useful. This commit switches as many ssh_hash_free / ssh_hash_new pairs as possible to reuse the previous hash object via ssh_hash_reset. Also a few other cleanups: use the wrapper function hash_simple() where possible, and I've also introduced ssh_hash_digest_nondestructive() and switched to that where possible as well.
2019-12-15 09:57:30 +00:00
ssh_hash_reset(pi->collectors[i]);
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
if (reseed_index & 1)
break;
reseed_index >>= 1;
}
sshprng.c: remove pointless pending_output buffer. In an early draft of the new PRNG, before I decided to get rid of random_byte() and replace it with random_read(), it was important after generating a hash-worth of PRNG output to buffer it so as to return it a byte at a time. So the PRNG data structure itself had to keep a hash-sized buffer of pending output, and be able to return the next byte from it on every random_byte() call. But when random_read() came in, there was no need to do that any more, because at the end of a read, the generator is re-seeded and the remains of any generated data is deliberately thrown away. So the pending_output buffer has no need to live in the persistent prng object; it can be relegated to a local variable inside random_read (and a couple of other functions that used the same buffer since it was conveniently there). A side effect of this is that we're no longer yielding the bytes of each hash in reverse order, because only the previous silly code structure made it convenient. Fortunately, of course, nothing is depending on that - except the cryptsuite tests, which I've updated.
2020-01-26 10:58:27 +00:00
smemclr(buf, sizeof(buf));
Replace PuTTY's PRNG with a Fortuna-like system. This tears out the entire previous random-pool system in sshrand.c. In its place is a system pretty close to Ferguson and Schneier's 'Fortuna' generator, with the main difference being that I use SHA-256 instead of AES for the generation side of the system (rationale given in comment). The PRNG implementation lives in sshprng.c, and defines a self- contained data type with no state stored outside the object, so you can instantiate however many of them you like. The old sshrand.c still exists, but in place of the previous random pool system, it's just become a client of sshprng.c, whose job is to hold a single global instance of the PRNG type, and manage its reference count, save file, noise-collection timers and similar administrative business. Advantages of this change include: - Fortuna is designed with a more varied threat model in mind than my old home-grown random pool. For example, after any request for random numbers, it automatically re-seeds itself, so that if the state of the PRNG should be leaked, it won't give enough information to find out what past outputs _were_. - The PRNG type can be instantiated with any hash function; the instance used by the main tools is based on SHA-256, an improvement on the old pool's use of SHA-1. - The new PRNG only uses the completely standard interface to the hash function API, instead of having to have privileged access to the internal SHA-1 block transform function. This will make it easier to revamp the hash code in general, and also it means that hardware-accelerated versions of SHA-256 will automatically be used for the PRNG as well as for everything else. - The new PRNG can be _tested_! Because it has an actual (if not quite explicit) specification for exactly what the output numbers _ought_ to be derived from the hashes of, I can (and have) put tests in cryptsuite that ensure the output really is being derived in the way I think it is. The old pool could have been returning any old nonsense and it would have been very hard to tell for sure.
2019-01-22 22:42:41 +00:00
prng_seed_finish(&pi->Prng);
}
}
Windows PuTTYgen: bound entropy input by PRNG state size. Although I've reinstated the tedious manual mouse input, I can at least reduce the amount of it that the user is required to provide: the new PRNG has a hard limit on the size of its seed, so once we've generated enough entropy to fill that up, there's no point in collecting more, even if we're generating a particularly large key.
2019-02-10 13:43:14 +00:00
size_t prng_seed_bits(prng *pr)
{
prng_impl *pi = container_of(pr, prng_impl, Prng);
return pi->hashalg->hlen * 8;
}
Reference in New Issue Copy Permalink