Commit graph

10 commits

Author SHA1 Message Date
David Goulet
ea14fb136c Merge branch 'tor-github/pr/1050' into maint-0.4.1 2019-06-11 11:29:46 -04:00
Nick Mathewson
93ddc51cbd Give a more useful failure messgae when we fail to minherit().
Part of ticket 30686.
2019-06-11 11:29:23 -04:00
Nick Mathewson
60213a3621 Run "make autostyle." 2019-06-05 09:33:35 -04:00
Nick Mathewson
587a525cc5 Add improved debugging support to crypto_rand_fast code. 2019-04-30 11:11:39 -04:00
Nick Mathewson
e66b5153bd Extract add-entropy code from crypto_fast_rng to a new function 2019-04-30 11:11:39 -04:00
Nick Mathewson
027c536598 rename inherit values to avoid conflict with system defines 2019-04-04 12:56:52 -04:00
Nick Mathewson
785c3f84de fast_rng: if noinherit has failed, then check getpid() for bad forks
getpid() can be really expensive sometimes, and it can fail to
detect some kind of fork+prng mistakes, so we need to avoid it if
it's safe to do so.

This patch might slow down fast_prng a lot on any old operating
system that lacks a way to prevent ram from being inherited, AND
requires a syscall for any getpid() calls.  But it should make sure
that we either crash or continue safely on incorrect fork+prng usage
elsewhere in the future.
2019-04-04 12:56:52 -04:00
Nick Mathewson
12205c3cbe Make map_anon expose the result of a noinherit attempt
Previously we did this for tests only, but it's valuable for getting
proper fork behavior in rand_fast.
2019-04-04 12:56:52 -04:00
Nick Mathewson
b25cd5cfe1 Implement code to manage a per-thread instance of crypto_fast_rng()
The subsystems API makes this really simple, fortunately.

Closes ticket 29536
2019-02-19 15:36:08 -05:00
Nick Mathewson
f3cbd6426c Implement a fast aes-ctr prng
This module is currently implemented to use the same technique as
libottery (later used by the bsds' arc4random replacement), using
AES-CTR-256 as its underlying stream cipher.  It's backtracking-
resistant immediately after each call, and prediction-resistant
after a while.

Here's how it works:

We generate psuedorandom bytes using AES-CTR-256.  We generate BUFLEN bytes
at a time.  When we do this, we keep the first SEED_LEN bytes as the key
and the IV for our next invocation of AES_CTR, and yield the remaining
BUFLEN - SEED_LEN bytes to the user as they invoke the PRNG.  As we yield
bytes to the user, we clear them from the buffer.

Every RESEED_AFTER times we refill the buffer, we mix in an additional
SEED_LEN bytes from our strong PRNG into the seed.

If the user ever asks for a huge number of bytes at once, we pull SEED_LEN
bytes from the PRNG and use them with our stream cipher to fill the user's
request.
2019-02-14 09:26:40 -05:00