aboutsummaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorMatt Caswell <matt@openssl.org>2015-02-26 13:52:30 +0000
committerMatt Caswell <matt@openssl.org>2015-03-25 12:38:19 +0000
commit302d38e3f73d5fd2ba2fd30bb7798778cb9f18dd (patch)
tree6564454eca01e9829c9c04e1724892d6ac23f4bb /doc
parent266483d2f56b0764849797f31866bfd84f9c3aa8 (diff)
downloadopenssl-302d38e3f73d5fd2ba2fd30bb7798778cb9f18dd.zip
openssl-302d38e3f73d5fd2ba2fd30bb7798778cb9f18dd.tar.gz
openssl-302d38e3f73d5fd2ba2fd30bb7798778cb9f18dd.tar.bz2
Deprecate RAND_pseudo_bytes
The justification for RAND_pseudo_bytes is somewhat dubious, and the reality is that it is frequently being misused. RAND_bytes and RAND_pseudo_bytes in the default implementation both end up calling ssleay_rand_bytes. Both may return -1 in an error condition. If there is insufficient entropy then both will return 0, but RAND_bytes will additionally add an error to the error queue. They both return 1 on success. Therefore the fundamental difference between the two is that one will add an error to the error queue with insufficient entory whilst the other will not. Frequently there are constructions of this form: if(RAND_pseudo_bytes(...) <= 1) goto err; In the above form insufficient entropy is treated as an error anyway, so RAND_bytes is probably the better form to use. This form is also seen: if(!RAND_pseudo_bytes(...)) goto err; This is technically not correct at all since a -1 return value is incorrectly handled - but this form will also treat insufficient entropy as an error. Within libssl it is required that you have correctly seeded your entropy pool and so there seems little benefit in using RAND_pseudo_bytes. Similarly in libcrypto many operations also require a correctly seeded entropy pool and so in most interesting cases you would be better off using RAND_bytes anyway. There is a significant risk of RAND_pseudo_bytes being incorrectly used in scenarios where security can be compromised by insufficient entropy. If you are not using the default implementation, then most engines use the same function to implement RAND_bytes and RAND_pseudo_bytes in any case. Given its misuse, limited benefit, and potential to compromise security, RAND_pseudo_bytes has been deprecated. Reviewed-by: Richard Levitte <levitte@openssl.org>
Diffstat (limited to 'doc')
-rw-r--r--doc/crypto/RAND_bytes.pod3
1 files changed, 3 insertions, 0 deletions
diff --git a/doc/crypto/RAND_bytes.pod b/doc/crypto/RAND_bytes.pod
index 1a9b91e..f3a5ed2 100644
--- a/doc/crypto/RAND_bytes.pod
+++ b/doc/crypto/RAND_bytes.pod
@@ -10,6 +10,8 @@ RAND_bytes, RAND_pseudo_bytes - generate random data
int RAND_bytes(unsigned char *buf, int num);
+Deprecated:
+
int RAND_pseudo_bytes(unsigned char *buf, int num);
=head1 DESCRIPTION
@@ -18,6 +20,7 @@ RAND_bytes() puts B<num> cryptographically strong pseudo-random bytes
into B<buf>. An error occurs if the PRNG has not been seeded with
enough randomness to ensure an unpredictable byte sequence.
+RAND_pseudo_bytes() has been deprecated. Users should use RAND_bytes() instead.
RAND_pseudo_bytes() puts B<num> pseudo-random bytes into B<buf>.
Pseudo-random byte sequences generated by RAND_pseudo_bytes() will be
unique if they are of sufficient length, but are not necessarily