Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:38:22Zhttps://gitlab.torproject.org/legacy/trac/-/issues/29536prng: Add a global fast PRNG object2020-06-13T15:38:22ZDavid Gouletdgoulet@torproject.orgprng: Add a global fast PRNG objectprop289 needs to have a fast PRNG allocated early in order to avoid creating a fast prng object every time we want to add random to a cell.prop289 needs to have a fast PRNG allocated early in order to avoid creating a fast prng object every time we want to add random to a cell.Tor: 0.4.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/17800Tor Unit Tests should TT_FORK before initialising global PRNG state2020-06-13T14:52:11ZteorTor Unit Tests should TT_FORK before initialising global PRNG stateTor unit tests are meant to TT_FORK before changing any global process state that can't be reverted.
In #17789, we discovered that one or more tests initialise the OpenSSL CSPRNG without forking first. (This can't be undone.)
While thi...Tor unit tests are meant to TT_FORK before changing any global process state that can't be reverted.
In #17789, we discovered that one or more tests initialise the OpenSSL CSPRNG without forking first. (This can't be undone.)
While this isn't likely to cause any issues, (#17789 was marked as wontfix for other reasons), it would be nice to fix it eventually for correctness.
One way to do this is:
* initialise a static variable to 0.
* set it to 1 just after fork()ing via TT_FORK.
* tor_assert() that it's 1 in functions that irreversibly modify global test process state, if TOR_UNIT_TESTS is defined:
* crypto_early_init(), which seeds the OpenSSL CSPRNG,
* (I'm sure many other init functions do similar things)
* mark the tests that assert as TT_FORK
Marked as Low/Minor because this doesn't currently cause any issues, but if tests start failing due to interactions with previous global state, we should look at it again.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/17799Use a better PRNG unless OpenSSL starts using a better one on their own.2020-06-13T14:52:10ZteorUse a better PRNG unless OpenSSL starts using a better one on their own.#17694 hashes important PRNG output with some system randomness before use, so that observed PRNG outputs are resistant to PRNG state analysis.
But almost all of Tor's use of PRNG outputs is observable from one or more locations outside...#17694 hashes important PRNG output with some system randomness before use, so that observed PRNG outputs are resistant to PRNG state analysis.
But almost all of Tor's use of PRNG outputs is observable from one or more locations outside Tor, whether in salts or nonces sent to other machines on the wire, or in the random choices made in guard, directory, and path selection.
We could hash all of the bytes coming from the PRNG to avoid this state exposure. (Although we might not need to use the system randomness source each time.)Tor: unspecifiedNick MathewsonNick Mathewson