diff options
author | miod <> | 2014-04-15 16:52:50 +0000 |
---|---|---|
committer | miod <> | 2014-04-15 16:52:50 +0000 |
commit | be03b064bffafbd378c0d5cc5971594573544d64 (patch) | |
tree | cd099da9298b8ab84a5dbbead9a6560737057c97 /src/lib/libcrypto/doc/RAND_add.pod | |
parent | f08ae3b01d60723e8f4334e0aaf4a57f03c478ba (diff) | |
download | openbsd-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.pod | 57 |
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 | ||
5 | RAND_add, RAND_seed, RAND_status, RAND_event, RAND_screen - add | 5 | RAND_add, RAND_seed, RAND_status - add entropy to the PRNG (DEPRECATED) |
6 | entropy 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 | ||
23 | RAND_add() mixes the B<num> bytes at B<buf> into the PRNG state. Thus, | 19 | These functions used to allow for the state of the random number generator |
24 | if the data at B<buf> are unpredictable to an adversary, this | 20 | to be controlled by external sources. |
25 | increases the uncertainty about the state and makes the PRNG output | ||
26 | less predictable. Suitable input comes from user interaction (random | ||
27 | key presses, mouse movements) and certain hardware events. The | ||
28 | B<entropy> argument is (the lower bound of) an estimate of how much | ||
29 | randomness is contained in B<buf>, measured in bytes. Details about | ||
30 | sources of randomness and how to estimate their entropy can be found | ||
31 | in the literature, e.g. RFC 1750. | ||
32 | |||
33 | RAND_add() may be called with sensitive data such as user entered | ||
34 | passwords. The seed values cannot be recovered from the PRNG output. | ||
35 | |||
36 | OpenSSL makes sure that the PRNG state is unique for each thread. On | ||
37 | systems that provide C</dev/urandom>, the randomness device is used | ||
38 | to seed the PRNG transparently. However, on all other systems, the | ||
39 | application is responsible for seeding the PRNG by calling RAND_add(), | ||
40 | L<RAND_egd(3)|RAND_egd(3)> | ||
41 | or L<RAND_load_file(3)|RAND_load_file(3)>. | ||
42 | |||
43 | RAND_seed() is equivalent to RAND_add() when B<num == entropy>. | ||
44 | |||
45 | RAND_event() collects the entropy from Windows events such as mouse | ||
46 | movements and other user interaction. It should be called with the | ||
47 | B<iMsg>, B<wParam> and B<lParam> arguments of I<all> messages sent to | ||
48 | the window procedure. It will estimate the entropy contained in the | ||
49 | event message (if any), and add it to the PRNG. The program can then | ||
50 | process the messages as usual. | ||
51 | 21 | ||
52 | The RAND_screen() function is available for the convenience of Windows | 22 | They are kept for ABI compatibility but are no longer functional, and |
53 | programmers. It adds the current contents of the screen to the PRNG. | 23 | should not used in new programs. |
54 | For applications that can catch Windows events, seeding the PRNG by | ||
55 | calling RAND_event() is a significantly better source of | ||
56 | randomness. It should be noted that both methods cannot be used on | ||
57 | servers that run without user interaction. | ||
58 | |||
59 | =head1 RETURN VALUES | ||
60 | |||
61 | RAND_status() and RAND_event() return 1 if the PRNG has been seeded | ||
62 | with enough data, 0 otherwise. | ||
63 | |||
64 | The other functions do not return values. | ||
65 | 24 | ||
66 | =head1 SEE ALSO | 25 | =head1 SEE ALSO |
67 | 26 | ||
68 | L<rand(3)|rand(3)>, L<RAND_egd(3)|RAND_egd(3)>, | 27 | L<rand(3)|rand(3)>, L<RAND_egd(3)|RAND_egd(3)>, |
69 | L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_cleanup(3)|RAND_cleanup(3)> | 28 | L<RAND_load_file(3)|RAND_load_file(3)>, L<RAND_cleanup(3)|RAND_cleanup(3)> |
70 | 29 | ||
71 | =head1 HISTORY | ||
72 | |||
73 | RAND_seed() and RAND_screen() are available in all versions of SSLeay | ||
74 | and OpenSSL. RAND_add() and RAND_status() have been added in OpenSSL | ||
75 | 0.9.5, RAND_event() in OpenSSL 0.9.5a. | ||
76 | |||
77 | =cut | 30 | =cut |