AIX 5.2 /dev/random and /dev/urandom devices

[Roberts, Iain I SITI-ITDGE12]

For info :

Unlike previous versions of AIX, AIX 5.2 has /dev/random and /dev/urandom devices.  There is not much documentation on them.  This is information I have obtained from IBM.

Summary :

Under AIX the /dev/random device only maintains an 8K entropy pool, replenished when it falls under 4K.  It also seems to be slower (or more selective) in gathering entropy than /dev/random on Linux (at least where I have tested, principally SuSE 8.1) .  For small amounts of entropy (under 4K) , /dev/random is appropriate.  For larger amounts, /dev/urandom is secure enough.

-----------------------
General information from 2nd line support :

9.20 Cryptographically secure pseudo-random numbers
AIX 5L Version 5.2 now supports a cryptographically secure pseudo-random
number generator (PRNG). Random numbers are extremely important for any
sort of cryptographic application. Random numbers are used to generate
session keys, salts used for hashed passwords, and initializing public
key certificates. If the generated random numbers are easily
predictable, any application using those insecure numbers is also
insecure. No algorithms or protocol can fix problems with random number
generation.
The PRNG on Version 5.2 is based on the Yarrow engine and collects
entropy from the running system and feeds an entropy pool to seed a
PRNG. The entropy gathering process selects three hardware devices upon
startup such as, SSA, Ethernet, and SCSI adapters. The entropy-gathering
daemon detects hardware interrupts or network packets and determines the
times between two events. These timings are then put into the entropy
pool.
The API for accessing the PRNG is quite simple. An application just has
to open the /dev/random or /dev/urandom file and read the required
number of bytes of the special device. The /dev/random and /dev/urandom
have different behaviors when the pool of entropy is exhausted or
requires reseeding. The /dev/random device will have the reading
application block until more entropy is gathered. The
/dev/urandom device will behave the same as /dev/random, but when
entropy is exhausted it will fall back and generate entropy using a
software algorithm. The level of randomness of the numbers generated by
the software algorithm is not as high as the entropy gathered from the
running system.
The PRNG automatically keeps the entropy pools replenished and reseeds
it occasionally. When the entropy pool is half empty, the entropy
gatherer will intercept the hardware interrupts and network packets
until the entropy is replenished. There is a slight performance penalty
while entropy is being gathered. When the pools are full, the
entropy-gathering process goes idle and no longer effects machine
performance.
For more information on the Yarrow engine, refer to the Counterpane Labs
home page at the following URL:
http://www.counterpane.com/yarrow.html

==============================================================

Files Reference
random and urandom Devices
Purpose
Source of secure random output.

Description
The /dev/random and /dev/urandom character devices provide
cryptographically secure random output generated from interrupt timings
or input written to the devices.

The /dev/random device is intended to provide high quality,
cryptographically secure random output and will only return output for
which sufficient (an equal or greater amount) random input is available
to generate the output. If insufficient random input is available, reads
from the /dev/random device will block until the request can be
fulfilled unless the O_NONBLOCK flag was specified when the device was
opened, in which case as much high quality output as could be generated
is returned with the error code EAGAIN.

The /dev/urandom device provides a reliable source of random output,
however the output will not be generated from an equal amount of random
input if insufficient input is available. Reads from the /dev/urandom
device always return the quantity of output requested without blocking.
If insufficient random input is available, alternate input will be
processed by the random number generator to provide cryptographically
secure output, the strength of which will reflect the strength of the
algorithms used by the random number generator. Output generated without
random input is theoretically less secure than output generated from
random input, so /dev/random should be used for applications for which a
high level of confidence in the security of the output is required.

Data written to either device is added to the pool of stored random
input and may be used for generating output. Writes behave identically
for both devices and will not block.

Implementation Specifics
The /dev/random and /dev/urandom devices are created from major and
minor numbers assigned by the device configuration subsystem when the
random number generator is loaded, so the device names should always be
used when attempting to locate or open the devices. The devices are
deleted when the random number generator is unloaded. When the system is
shut down using the shutdown command, output is taken from the
/dev/urandom device and is written back to the /dev/random device when
the random number generator is loaded on the next boot to provide
starting entropy to the generator, enhancing the quality of the stored
random input after boot.

Input is gathered from interrupt timings when the pool of stored random
input falls below half full and continues to be gathered until the pool
is again full. This process causes a minor performance impact to all
external interrupts while timings are being gathered, which ceases when
timings cease to be gathered. Data written to either of the random
devices will also contribute to the pool of stored random input and can
influence the output, thus writing to these devices should be a
privileged operation. This is enforced by the permissions of the
devices, so it can be changed by the administrator to be completely
disallowed if desired.

--------------------------------

More detailed information from the developer


This is working as designed.  AIX's entropy collector for /dev/random is
much more selective about what entropy is accepted than other systems to
ensure that only true entropy is accepted to the entropy store.  Timings
are collected from all external interrupts and all overlap from previous
timings as well as a extra measure are discarded.  Note that block IO
such as disk IO or large network transfers generate fewer interrupts per
data processed than interactive IO such as X traffic or a user typing,
and thus generate less entropy input.  The entropy store is 8K and
begins to collect entropy again when stored entropy drops below 4K.  It
was determined that this was the correct balance between system
performance (collecting entropy causes overhead in each interrupt), the
risk of using entropy stored for a long time which carries a greater
potential of being compromised, and acceptable response to user requests
for random output.  AIX's /dev/random is not designed to generate bulk
entropy, but to provide small quantities of high-quality entropy for
cryptographic applications or to seed a linear-type random number
generator that produces bulk output.  Other systems' implementations of
/dev/random with less strict standards of security do of course generate
more output from less input more quickly.  If you need a greater
quantity of entropy from AIX's generator, use /dev/urandom, whose output
will be identical to /dev/random when entropy is available and only be
vulnerable to attacks on the hash and cryptographic algorithms used when
entropy is not available.  The SHA-1 and AES (Rijndael) algorithms are
used, which are considered to be of high quality and are not known to
have been successfully attacked, so /dev/urandom provides output which
is objectively of the same quality as /dev/random but is more vulnerable
to theoretical attacks and is acceptable for all but the most sensitive
applications.  If the customer requires a larger burst of output, they
may submit a FITS request (DCR) for entropy store size and threshold to
be increased, but the algorithm for collecting entropy will not be
changed, as that would unacceptably compromise the quality of output,
which is the design objective.  In regard to the customer's remarks
about reboot, 512 bytes are stored at shutdown for use at boot, so the
rest of the stored entropy is discarded.  This is to provide a balance
between the risk of collecting entropy from the highly regular boot
sequence with the risk of using entropy stored on disk, which is much
more likely to have been compromised.

-----------------------------------------------



 
Iain Roberts 
iain at cairnlin.co.uk
0xF9AA56D3
                                                            

-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20030425/d021a7e1/attachment.htm