Fix & update documentation about RAND_priv_bytes()
authorNicola Tuveri <nic.tuv@gmail.com>
Mon, 18 Jun 2018 16:13:36 +0000 (19:13 +0300)
committerDr. Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
Tue, 19 Jun 2018 15:06:38 +0000 (17:06 +0200)
Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Ben Kaduk <kaduk@mit.edu>
Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre@ncp-e.com>
(Merged from https://github.com/openssl/openssl/pull/6514)

doc/man3/BN_rand.pod
doc/man3/RAND_bytes.pod
doc/man7/RAND.pod

index 099dda47e9f88cbb98b32aecc30361d3e77bf8ce..eb0a6b13862fe6c99577c53e48d9e580ea276ba6 100644 (file)
@@ -2,7 +2,9 @@
 
 =head1 NAME
 
-BN_rand, BN_pseudo_rand, BN_rand_range, BN_pseudo_rand_range - generate pseudo-random number
+BN_rand, BN_priv_rand, BN_pseudo_rand,
+BN_rand_range, BN_priv_rand_range, BN_pseudo_rand_range
+- generate pseudo-random number
 
 =head1 SYNOPSIS
 
@@ -10,10 +12,14 @@ BN_rand, BN_pseudo_rand, BN_rand_range, BN_pseudo_rand_range - generate pseudo-r
 
  int BN_rand(BIGNUM *rnd, int bits, int top, int bottom);
 
+ int BN_priv_rand(BIGNUM *rnd, int bits, int top, int bottom);
+
  int BN_pseudo_rand(BIGNUM *rnd, int bits, int top, int bottom);
 
  int BN_rand_range(BIGNUM *rnd, BIGNUM *range);
 
+ int BN_priv_rand_range(BIGNUM *rnd, BIGNUM *range);
+
  int BN_pseudo_rand_range(BIGNUM *rnd, BIGNUM *range);
 
 =head1 DESCRIPTION
@@ -37,7 +43,16 @@ If B<bits> is 1 then B<top> cannot also be B<BN_RAND_FLG_TOPTWO>.
 BN_rand_range() generates a cryptographically strong pseudo-random
 number B<rnd> in the range 0 E<lt>= B<rnd> E<lt> B<range>.
 
-The PRNG must be seeded prior to calling BN_rand() or BN_rand_range().
+BN_priv_rand() and BN_priv_rand_range() have the same semantics as
+BN_rand() and BN_rand_range() respectively.  They are intended to be
+used for generating values that should remain private, and mirror the
+same difference between L<RAND_bytes(3)> and L<RAND_priv_bytes(3)>.
+
+=head1 NOTES
+
+Always check the error return value of these functions and do not take
+randomness for granted: an error occurs if the CSPRNG has not been
+seeded with enough randomness to ensure an unpredictable byte sequence.
 
 =head1 RETURN VALUES
 
@@ -46,20 +61,34 @@ The error codes can be obtained by L<ERR_get_error(3)>.
 
 =head1 HISTORY
 
-Starting with OpenSSL release 1.1.0,
-BN_pseudo_rand() has been identical to BN_rand()
-and
-BN_pseudo_rand_range() has been identical to BN_rand_range().
+=over 2
+
+=item *
+
+Starting with OpenSSL release 1.1.0, BN_pseudo_rand() has been identical
+to BN_rand() and BN_pseudo_rand_range() has been identical to
+BN_rand_range().
 The "pseudo" functions should not be used and may be deprecated in
 a future release.
 
+=item *
+
+BN_priv_rand() and BN_priv_rand_range() were added in OpenSSL 1.1.1.
+
+=back
+
 =head1 SEE ALSO
 
-L<ERR_get_error(3)>, L<RAND_add(3)>, L<RAND_bytes(3)>
+L<ERR_get_error(3)>,
+L<RAND_add(3)>,
+L<RAND_bytes(3)>,
+L<RAND_priv_bytes(3)>,
+L<RAND(7)>,
+L<RAND_DRBG(7)>
 
 =head1 COPYRIGHT
 
-Copyright 2000-2017 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2000-2018 The OpenSSL Project Authors. All Rights Reserved.
 
 Licensed under the OpenSSL license (the "License").  You may not use
 this file except in compliance with the License.  You can obtain a copy
index 284b9dbe4da60240ed98fb9643fba78fc4dcea42..fca1ad6961debc193f2525c2f5c13161df702760 100644 (file)
@@ -20,13 +20,21 @@ Deprecated:
 =head1 DESCRIPTION
 
 RAND_bytes() puts B<num> cryptographically strong pseudo-random bytes
-into B<buf>. An error occurs if the CSPRNG has not been seeded with
-enough randomness to ensure an unpredictable byte sequence.
+into B<buf>.
 
 RAND_priv_bytes() has the same semantics as RAND_bytes().  It is intended to
-be used for generating long-term private keys. If using the default
-RAND_METHOD, this function uses a separate instance of the PRNG so that
-a compromise of the global generator will not affect such key generation.
+be used for generating values that should remain private. If using the
+default RAND_METHOD, this function uses a separate "private" PRNG
+instance so that a compromise of the "public" PRNG instance will not
+affect the secrecy of these private values, as described in L<RAND(7)>
+and L<RAND_DRBG(7)>.
+
+=head1 NOTES
+
+Always check the error return value of RAND_bytes() and
+RAND_priv_bytes() and do not take randomness for granted: an error occurs
+if the CSPRNG has not been seeded with enough randomness to ensure an
+unpredictable byte sequence.
 
 =head1 RETURN VALUES
 
@@ -37,14 +45,26 @@ obtained by L<ERR_get_error(3)>.
 
 =head1 HISTORY
 
+=over 2
+
+=item *
+
 RAND_pseudo_bytes() was deprecated in OpenSSL 1.1.0; use RAND_bytes() instead.
 
+=item *
+
+RAND_priv_bytes() was added in OpenSSL 1.1.1.
+
+=back
+
 =head1 SEE ALSO
 
 L<RAND_add(3)>,
 L<RAND_bytes(3)>,
+L<RAND_priv_bytes(3)>,
 L<ERR_get_error(3)>,
-L<RAND(7)>
+L<RAND(7)>,
+L<RAND_DRBG(7)>
 
 =head1 COPYRIGHT
 
index 578018feabc9c01326b3bb74c0442edd64e588fa..971b3cdb161287a62c6b64191da579ddc8fa53d6 100644 (file)
@@ -24,16 +24,19 @@ to be initialized ('seeded') explicitly.
 It seeds and reseeds itself automatically using trusted random sources
 provided by the operating system.
 
-As a normal application developer, you don't have to worry about any details,
+As a normal application developer, you do not have to worry about any details,
 just use L<RAND_bytes(3)> to obtain random data.
 Having said that, there is one important rule to obey: Always check the error
-return value of L<RAND_bytes(3)> and don't take randomness for granted.
+return value of L<RAND_bytes(3)> and do not take randomness for granted.
 
-For long-term secrets, you can use L<RAND_priv_bytes(3)> instead.
+For values that should remain secret, 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.
+The intention behind using a dedicated CSPRNG exclusively for private
+values 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, and that a compromise of the "public"
+CSPRNG instance will not affect the secrecy of these private values.
 
 In the rare case where the default implementation does not satisfy your special
 requirements, there are two options:
@@ -61,10 +64,10 @@ of cryptographic principles and understand the implications of your changes.
 L<RAND_add(3)>,
 L<RAND_bytes(3)>,
 L<RAND_priv_bytes(3)>,
-L<RAND_get_rand_method(3)>
-L<RAND_set_rand_method(3)>
+L<RAND_get_rand_method(3)>,
+L<RAND_set_rand_method(3)>,
 L<RAND_OpenSSL(3)>,
-L<RAND_DRBG(7)>,
+L<RAND_DRBG(7)>
 
 =head1 COPYRIGHT