s***@public.gmane.org
2003-04-28 09:11:37 UTC
Från: Lutz Jaenicke <Lutz.Jaenicke-XTec+feGiB/2g9D+***@public.gmane.org> den 2003-04-27 13:14 ZE2
Sänd svar till openssl-users-MCmKBN63+***@public.gmane.org@***@Meriposti
Till: openssl-users-MCmKBN63+***@public.gmane.org@***@Meriposti
Kopia:
Ärende: Re: IBM AIX 5.2 with /dev/random - Zlib 1.1.4 - OpenSSL 0.9.7.b - OpenSSH 3.6.1p1 - PRNG is not seeded
AIX 5.2!!
anything to do. In this case: it indicates that there is no data
available at /dev/urandom!
[more data deleted]
OpenSSL uses select() to see, whether data are available on /dev/urandom
before actually trying to read from it.
From your experiments it seems, that select() does not properly handle
the /dev/urandom device file: it does not indicate data available
(OpenSSL fails) even though it would provide bytes on read() (cat
succeeds).
I consider this to be a bug in the AIX 5.2 select() routine. Please file
a bug report.
Best regards,
Lutz
PS. There seems to be another problem below the one seen: cat /dev/random
fails, indicating the the internal RNG in the kernel is not properly
seeded anyway. Maybe when seeded correctly, the select() call would succeed
as well. (The select() behaviour reported still being buggy.)
--
Lutz Jaenicke Lutz.Jaenicke-XTec+feGiB/2g9D+***@public.gmane.org
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Hi,
OpenSSL 0.9.6j works with AIX 5.2 /dev/urandom
OpenSSL 0.9.7b does NOT work with AIX 5.2 /dev/urandom
This is the response from IBM regarding the behavior
of /dev/random and /dev/urandom on AIX 5.2
----------------------------------------------------------------
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.
----------------------------------------------------------------
Kind Regards
Stefan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Sänd svar till openssl-users-MCmKBN63+***@public.gmane.org@***@Meriposti
Till: openssl-users-MCmKBN63+***@public.gmane.org@***@Meriposti
Kopia:
Ärende: Re: IBM AIX 5.2 with /dev/random - Zlib 1.1.4 - OpenSSL 0.9.7.b - OpenSSH 3.6.1p1 - PRNG is not seeded
I am trying to compile the latest version of OpenSSL on
AIX 5.2 to use /dev/urandom and failes misserably!
This is already the second report about problems with /dev/urandom onAIX 5.2 to use /dev/urandom and failes misserably!
AIX 5.2!!
All I get when I try to start sshd is the following!
aixws1:/# /usr/local/sbin/sshd
PRNG is not seeded
aixws1:/#
aixws1:/# /usr/local/sbin/sshd -ddd
PRNG is not seeded
aixws1:/#
aixws1:/# truss /usr/local/sbin/sshd -D
execve("/usr/local/sbin/sshd", 0x2FF22BA8, 0x2FF22BB4) argc: 2
__loadx(0x0A040000, 0xD03389AC, 0x00000004, 0x10000000, 0x200003AA) = 0x00000000
sbrk(0x00000000) = 0x2001A960
sbrk(0x00010010) = 0x2001A960
_getpid() = 17386
_getpid() = 17386
Is truss known to be totally accurate? (Well I suppose it is.)aixws1:/# /usr/local/sbin/sshd
PRNG is not seeded
aixws1:/#
aixws1:/# /usr/local/sbin/sshd -ddd
PRNG is not seeded
aixws1:/#
aixws1:/# truss /usr/local/sbin/sshd -D
execve("/usr/local/sbin/sshd", 0x2FF22BA8, 0x2FF22BB4) argc: 2
__loadx(0x0A040000, 0xD03389AC, 0x00000004, 0x10000000, 0x200003AA) = 0x00000000
sbrk(0x00000000) = 0x2001A960
sbrk(0x00010010) = 0x2001A960
_getpid() = 17386
_getpid() = 17386
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 3
/dev/urandom is opened fine._select(4, 0x2FF20158, 0x00000000, 0x00000000, 0x2FF22160) = 0
select() returns 0, meaning that it actually does not believe there isanything to do. In this case: it indicates that there is no data
available at /dev/urandom!
close(3) = 0
File descriptor closed again[more data deleted]
aixws1:/#
aixws1:/# ls -al /dev/*random
crw-r--r-- 1 root system 43, 0 Apr 15 09:21 /dev/random
crw-r--r-- 1 root system 43, 1 Apr 15 09:21 /dev/urandom
aixws1:/#
The following hangs and just creates an empty file randomtest.
Should it be like that?
aixws1:/#cat /dev/random > ./randomtest
If no random data are available, it should hang.aixws1:/# ls -al /dev/*random
crw-r--r-- 1 root system 43, 0 Apr 15 09:21 /dev/random
crw-r--r-- 1 root system 43, 1 Apr 15 09:21 /dev/urandom
aixws1:/#
The following hangs and just creates an empty file randomtest.
Should it be like that?
aixws1:/#cat /dev/random > ./randomtest
aixws1:/#
The following creates the file urandomtest and it is full with "random"
data!
aixws1:/#cat /dev/urandom > ./urandomtest
aixws1:/#
This should never terminate itself and fill the file until ^C is pressed!?The following creates the file urandomtest and it is full with "random"
data!
aixws1:/#cat /dev/urandom > ./urandomtest
aixws1:/#
What have I done wrong regarding OpenSSL?
No.Shouldn't OpenSSL use /dev/urandom if that device exist?
Yes.OpenSSL uses select() to see, whether data are available on /dev/urandom
before actually trying to read from it.
From your experiments it seems, that select() does not properly handle
the /dev/urandom device file: it does not indicate data available
(OpenSSL fails) even though it would provide bytes on read() (cat
succeeds).
I consider this to be a bug in the AIX 5.2 select() routine. Please file
a bug report.
Best regards,
Lutz
PS. There seems to be another problem below the one seen: cat /dev/random
fails, indicating the the internal RNG in the kernel is not properly
seeded anyway. Maybe when seeded correctly, the select() call would succeed
as well. (The select() behaviour reported still being buggy.)
--
Lutz Jaenicke Lutz.Jaenicke-XTec+feGiB/2g9D+***@public.gmane.org
http://www.aet.TU-Cottbus.DE/personen/jaenicke/
BTU Cottbus, Allgemeine Elektrotechnik
Universitaetsplatz 3-4, D-03044 Cottbus
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org
Hi,
OpenSSL 0.9.6j works with AIX 5.2 /dev/urandom
OpenSSL 0.9.7b does NOT work with AIX 5.2 /dev/urandom
This is the response from IBM regarding the behavior
of /dev/random and /dev/urandom on AIX 5.2
----------------------------------------------------------------
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.
----------------------------------------------------------------
Kind Regards
Stefan
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users-MCmKBN63+***@public.gmane.org
Automated List Manager majordomo-MCmKBN63+***@public.gmane.org