Incorporate some additional data into the RNG state. For example adding nonces or timestamps from a peer's protocol message can help hedge against VM state rollback attacks. A few RNG types do not accept any externally provided input, in which case this function is a no-op.

Incorporate entropy into the RNG state then produce output. Some RNG types implement this using a single operation, default calls add_entropy + randomize in sequence.

Use this to further bind the outputs to your current process/protocol state. For instance if generating a new key for use in a session, include a session ID or other such value. See NIST SP 800-90 A, B, C series for more ideas.

For a stateful RNG using non-random but potentially unique data the extra input can help protect against problems with fork, VM state rollback, or other cases where somehow an RNG state is duplicated. If both of the duplicated RNG states later incorporate a timestamp (and the timestamps don't themselves repeat), their outputs will diverge.