Minor corrections for the RAND_DRBG API documentation

- added some explaining text to a sentence that lost its context.
- removed mention of per-ssl drbg
- fix whitespace errors
Reviewed-by: NRich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/5804)

doc/man3/RAND_DRBG_set_callbacks.pod

@@ -79,7 +79,7 @@ See NOTES section for more details.
 
 The B<cleanup_entropy>() callback is called from the B<drbg> to to clear and
 free the buffer allocated previously by get_entropy().
-The values B<out> and B<outlen> are the random buffer's  address and length,
+The values B<out> and B<outlen> are the random buffer's address and length,
 as returned by the get_entropy() callback.
 
 The B<get_nonce>() and B<cleanup_nonce>() callbacks are used to obtain a nonce

doc/man7/RAND.pod

@@ -32,8 +32,8 @@ return value of L<RAND_bytes(3)> and don't take randomness for granted.
 For long-term secrets, you can use L<RAND_priv_bytes(3)> instead.
 This method does not provide 'better' randomness, it uses the same type of CSPRNG.
 The intention behind using a dedicated CSPRNG exclusively for long-term secrets is
-that none  of its output should be visible to an attacker (e.g used as salt value),
-in order  to reveal as little information as possible about its internal state.
+that none of its output should be visible to an attacker (e.g used as salt value),
+in order to reveal as little information as possible about its internal state.
 
 In the rare case where the default implementation does not satisfy your special
 requirements, there are two options:

doc/man7/RAND_DRBG.pod

@@ -37,8 +37,7 @@ Typical examples for such special use cases are the following:
 
 =item *
 
-You want to use your own private DRBG instances, similar to how it
-is currently done in the ssl library.
+You want to use your own private DRBG instances.
 Multiple DRBG instances which are accessed only by a single thread provide
 additional security (because their internal states are independent) and
 better scalability in multithreaded applications (because they don't need
@@ -80,8 +79,8 @@ the thread-local <public> and <private> DRBG instance, respectively.
 =head2 The <master> DRBG instance
 
 The <master> DRBG is not used directly by the application, only for reseeding
-the two other two  DRBG instances. It reseeds itself by obtaining randomness
-either from os entropy  sources or by consuming randomness which was added
+the two other two DRBG instances. It reseeds itself by obtaining randomness
+either from os entropy sources or by consuming randomness which was added
 previously by L<RAND_add(3)>.
 
 =head2 The <public> DRBG instance
@@ -144,10 +143,12 @@ together and are being used.
     +------------------+      +------------------------------------+
 
 
-
-The method L<RAND_DRBG_bytes(3)> is a convenience method wrapping the
-L<RAND_DRBG_generate(3)> function, which serves the actual request for
-random data.
+The usual way to obtain random bytes is to call RAND_bytes(...) or
+RAND_priv_bytes(...). These calls are roughly equivalent to calling
+RAND_DRBG_bytes(<public>, ...) and RAND_DRBG_bytes(<private>, ...),
+respectively. The method L<RAND_DRBG_bytes(3)> is a convenience method
+wrapping the L<RAND_DRBG_generate(3)> function, which serves the actual
+request for random data.
 
 =head1 RESEEDING