1IPSEC_PRNG(3) Library Functions Manual IPSEC_PRNG(3)
2
6 ipsec prng_init - initialize IPsec pseudorandom-number generator
7 ipsec prng_bytes - get bytes from IPsec pseudorandom-number generator
8 ipsec prng_final - close down IPsec pseudorandom-number generator
9
11 #include <freeswan.h>
12 void prng_init(struct prng *prng,
14 const unsigned char *key, size_t keylen);
15 void prng_bytes(struct prng *prng, char *dst,
16 size_t dstlen);
17 unsigned long prng_count(struct prng *prng);
18 void prng_final(struct prng *prng);
19
21 Prng_init initializes a crypto-quality pseudo-random-number generator
22 from a key; prng_bytes obtains pseudo-random bytes from it; prng_count
23 reports the number of bytes extracted from it to date; prng_final
24 closes it down. It is the user's responsibility to initialize a PRNG
25 before using it, and not to use it again after it is closed down.
26 Prng_init initializes, or re-initializes, the specified prng from the
28 key, whose length is given by keylen. The user must allocate the
29 struct prng pointed to by prng. There is no particular constraint on
30 the length of the key, although a key longer than 256 bytes is unneces‐
31 sary because only the first 256 would be used. Initialization requires
32 on the order of 3000 integer operations, independent of key length.
33 Prng_bytes obtains dstlen pseudo-random bytes from the PRNG and puts
35 them in buf. This is quite fast, on the order of 10 integer operations
36 per byte.
37 Prng_count reports the number of bytes obtained from the PRNG since it
39 was (last) initialized.
40 Prng_final closes down a PRNG by zeroing its internal memory, obliter‐
42 ating all trace of the state used to generate its previous output.
43 This requires on the order of 250 integer operations.
44 The <freeswan.h> header file supplies the definition of the prng struc‐
46 ture. Examination of its innards is discouraged, as they may change.
47 The PRNG algorithm used by these functions is currently identical to
49 that of RC4(TM). This algorithm is cryptographically strong, suffi‐
50 ciently unpredictable that even a hostile observer will have difficulty
51 determining the next byte of output from past history, provided it is
52 initialized from a reasonably large key composed of highly random bytes
53 (see random(4)). The usual run of software pseudo-random-number gener‐
54 ators (e.g. random(3)) are not cryptographically strong.
55 The well-known attacks against RC4(TM), e.g. as found in 802.11b's WEP
57 encryption system, apply only if multiple PRNGs are initialized with
58 closely-related keys (e.g., using a counter appended to a base key).
59 If such keys are used, the first few hundred pseudo-random bytes from
60 each PRNG should be discarded, to give the PRNGs a chance to randomize
61 their innards properly. No useful attacks are known if the key is well
62 randomized to begin with.
63
65 random(3), random(4)
66 Bruce Schneier, Applied Cryptography, 2nd ed., 1996, ISBN
67 0-471-11709-9, pp. 397-8.
68
70 Written for the FreeS/WAN project by Henry Spencer.
71
73 If an attempt is made to obtain more than 4e9 bytes between initializa‐
74 tions, the PRNG will continue to work but prng_count's output will
75 stick at 4000000000. Fixing this would require a longer integer type
76 and does not seem worth the trouble, since you should probably re-ini‐
77 tialize before then anyway...
78 ``RC4'' is a trademark of RSA Data Security, Inc.
80 1 April 2002 IPSEC_PRNG(3)