Also, explicitly state when routerinfos and extra-infos are signed.
And tidy up some other comments.

Preparation for testing 29017 and 20918.

This refactoring improves the structure of router_build_fresh_descriptor().

Preparation for testing 29017 and 20918.

Remove router_update_info_send_unencrypted(), and move its code into the
relevant functions.

Then, re-use an options pointer.

Preparation for testing 29017 and 20918.

Remove some tiny static functions called by router_build_fresh_descriptor(),
and move their code into more relevant functions.

Then, give router_update_{router,extra}info_descriptor_body identical layouts.

Preparation for testing 29017 and 20918.

Make sure that these static functions aren't passed NULL.
If they are, log a BUG() warning, and return an error.

Preparation for testing 29017 and 20918.

Tidy the arguments and return values of these functions, and clean up their
memory management.

Preparation for testing 29017 and 20918.

Split the body of router_build_fresh_descriptor() into static functions,
by inserting function prologues and epilogues between existing sections.

Write a new body for router_build_fresh_descriptor() that calls the new
static functions.

Initial refactor with no changes to the body of the old
router_build_fresh_descriptor(), except for the split.

Preparation for testing 29017 and 20918.

When ExtraInfoStatistics is 0, stop including bandwidth usage statistics,
GeoIPFile hashes, ServerTransportPlugin lines, and bridge statistics
by country in extra-info documents.

Fixes bug 29018; bugfix on 0.2.4.1-alpha (and earlier versions).

introduced in 85542ee5

next step is to fix it in torspec too

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.

test_crypto.c is pretty big; it wouldn't hurt to split it up some
more before I start adding stuff to the PRNG tests.

This is the second part of refactoring the random-int-in-range code.

Nick Mathewson authored 6 years ago and David Goulet committed 6 years ago

Fixes bug 28614; bugfix on 0.4.0.1-alpha when we started mmapping
the consensus.