mirror/openssl
2
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-12-21 06:09:35 +08:00
Code Issues Packages Projects Releases Wiki Activity
cddd424a5b
openssl/doc/crypto/RAND_bytes.pod

48 lines
1.4 KiB
Plaintext
Raw Normal View History

Document RAND library.
2000-01-22 01:50:27 +08:00
=pod
=head1 NAME
nicer manpages
2000-02-24 19:55:57 +08:00
RAND_bytes, RAND_pseudo_bytes - generate random data
Document RAND library.
2000-01-22 01:50:27 +08:00
=head1 SYNOPSIS
#include <openssl/rand.h>
int RAND_bytes(unsigned char *buf, int num);
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>
2015-02-26 21:52:30 +08:00
Deprecated:
Document RAND library.
2000-01-22 01:50:27 +08:00
int RAND_pseudo_bytes(unsigned char *buf, int num);
=head1 DESCRIPTION
Avoid integer overflow in entropy counter. Slightly clarify the RAND_... documentation.
2000-01-22 03:54:22 +08:00
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.
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>
2015-02-26 21:52:30 +08:00
RAND_pseudo_bytes() has been deprecated. Users should use RAND_bytes() instead.
Avoid integer overflow in entropy counter. Slightly clarify the RAND_... documentation.
2000-01-22 03:54:22 +08:00
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
unpredictable. They can be used for non-cryptographic purposes and for
certain purposes in cryptographic protocols, but usually not for key
generation etc.
Document RAND library.
2000-01-22 01:50:27 +08:00
Port from 0.9.8-stable
2007-09-24 19:01:18 +08:00
The contents of B<buf> is mixed into the entropy pool before retrieving
the new pseudo-random bytes unless disabled at compile time (see FAQ).
Document RAND library.
2000-01-22 01:50:27 +08:00
=head1 RETURN VALUES
RAND_bytes() returns 1 on success, 0 otherwise. The error code can be
Fix L<> content in manpages L<foo|foo> is sub-optimal If the xref is the same as the title, which is what we do, then you only need L<foo>. This fixes all 1457 occurrences in 349 files. Approximately. (And pod used to need both.) Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-08-18 03:21:33 +08:00
obtained by L<ERR_get_error(3)>. RAND_pseudo_bytes() returns 1 if the
Document RAND library.
2000-01-22 01:50:27 +08:00
bytes generated are cryptographically strong, 0 otherwise. Both
functions return -1 if they are not supported by the current RAND
method.
=head1 SEE ALSO
Fix L<> content in manpages L<foo|foo> is sub-optimal If the xref is the same as the title, which is what we do, then you only need L<foo>. This fixes all 1457 occurrences in 349 files. Approximately. (And pod used to need both.) Reviewed-by: Richard Levitte <levitte@openssl.org>
2015-08-18 03:21:33 +08:00
L<rand(3)>, L<ERR_get_error(3)>,
L<RAND_add(3)>
Document RAND library.
2000-01-22 01:50:27 +08:00
=cut
Reference in New Issue Copy Permalink