summaryrefslogtreecommitdiff
path: root/src/lib/libcrypto/doc/RAND_add.pod
diff options
context:
space:
mode:
authormiod <>2014-04-15 16:52:50 +0000
committermiod <>2014-04-15 16:52:50 +0000
commitbe03b064bffafbd378c0d5cc5971594573544d64 (patch)
treecd099da9298b8ab84a5dbbead9a6560737057c97 /src/lib/libcrypto/doc/RAND_add.pod
parentf08ae3b01d60723e8f4334e0aaf4a57f03c478ba (diff)
downloadopenbsd-be03b064bffafbd378c0d5cc5971594573544d64.tar.gz
openbsd-be03b064bffafbd378c0d5cc5971594573544d64.tar.bz2
openbsd-be03b064bffafbd378c0d5cc5971594573544d64.zip
Replace the old OpenSSL PRNG by direct use of arc4random_buf(), keeping the
existing RAND interfaces unchanged. All interfaces allowing external feed or seed of the RNG (either from a file or a local entropy gathering daemon) are kept for ABI compatibility, but are no longer do anything. While the OpenSSL PRNG was required 15+ years ago when many systems lacked proper entropy collection, things have evolved and one can reasonably assume it is better to use the kernel (system global) entropy pool rather than trying to build one's own and having to compensate for thread scheduling... <RANT> Whoever thought that RAND_screen(), feeding the PRNG with the contents of the local workstation's display, under Win32, was a smart idea, ought to be banned from security programming. </RANT> ok beck@ deraadt@ tedu@
Diffstat (limited to 'src/lib/libcrypto/doc/RAND_add.pod')
-rw-r--r--src/lib/libcrypto/doc/RAND_add.pod57
1 files changed, 5 insertions, 52 deletions
diff --git a/src/lib/libcrypto/doc/RAND_add.pod b/src/lib/libcrypto/doc/RAND_add.pod
index 67c66f3e0c..d55dc125d3 100644
--- a/src/lib/libcrypto/doc/RAND_add.pod
+++ b/src/lib/libcrypto/doc/RAND_add.pod
@@ -2,8 +2,7 @@
2 2
3=head1 NAME 3=head1 NAME
4 4
5RAND_add, RAND_seed, RAND_status, RAND_event, RAND_screen - add 5RAND_add, RAND_seed, RAND_status - add entropy to the PRNG (DEPRECATED)
6entropy to the PRNG
7 6
8=head1 SYNOPSIS 7=head1 SYNOPSIS
9 8
@@ -15,63 +14,17 @@ entropy to the PRNG
15 14
16 int RAND_status(void); 15 int RAND_status(void);
17 16
18 int RAND_event(UINT iMsg, WPARAM wParam, LPARAM lParam);
19 void RAND_screen(void);
20
21=head1 DESCRIPTION 17=head1 DESCRIPTION
22 18
23RAND_add() mixes the B<num> bytes at B<buf> into the PRNG state. Thus, 19These functions used to allow for the state of the random number generator
24if the data at B<buf> are unpredictable to an adversary, this 20to be controlled by external sources.
25increases the uncertainty about the state and makes the PRNG output
26less predictable. Suitable input comes from user interaction (random
27key presses, mouse movements) and certain hardware events. The
28B<entropy> argument is (the lower bound of) an estimate of how much
29randomness is contained in B<buf>, measured in bytes. Details about
30sources of randomness and how to estimate their entropy can be found
31in the literature, e.g. RFC 1750.
32
33RAND_add() may be called with sensitive data such as user entered
34passwords. The seed values cannot be recovered from the PRNG output.
35
36OpenSSL makes sure that the PRNG state is unique for each thread. On
37systems that provide C</dev/urandom>, the randomness device is used
38to seed the PRNG transparently. However, on all other systems, the
39application is responsible for seeding the PRNG by calling RAND_add(),
40L<RAND_egd(3)|RAND_egd(3)>
41or L<RAND_load_file(3)|RAND_load_file(3)>.
42
43RAND_seed() is equivalent to RAND_add() when B<num == entropy>.
44
45RAND_event() collects the entropy from Windows events such as mouse
46movements and other user interaction. It should be called with the
47B<iMsg>, B<wParam> and B<lParam> arguments of I<all> messages sent to
48the window procedure. It will estimate the entropy contained in the
49event message (if any), and add it to the PRNG. The program can then
50process the messages as usual.
51 21
52The RAND_screen() function is available for the convenience of Windows 22They are kept for ABI compatibility but are no longer functional, and
53programmers. It adds the current contents of the screen to the PRNG. 23should not used in new programs.
54For applications that can catch Windows events, seeding the PRNG by
55calling RAND_event() is a significantly better source of
56randomness. It should be noted that both methods cannot be used on
57servers that run without user interaction.
58
59=head1 RETURN VALUES
60
61RAND_status() and RAND_event() return 1 if the PRNG has been seeded
62with enough data, 0 otherwise.
63
64The other functions do not return values.
65 24
66=head1 SEE ALSO 25=head1 SEE ALSO
67 26
68L<rand(3)|rand(3)>, L<RAND_egd(3)|RAND_egd(3)>, 27L<rand(3)|rand(3)>, L<RAND_egd(3)|RAND_egd(3)>,
69L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_cleanup(3)|RAND_cleanup(3)> 28L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_cleanup(3)|RAND_cleanup(3)>
70 29
71=head1 HISTORY
72
73RAND_seed() and RAND_screen() are available in all versions of SSLeay
74and OpenSSL. RAND_add() and RAND_status() have been added in OpenSSL
750.9.5, RAND_event() in OpenSSL 0.9.5a.
76
77=cut 30=cut