On Thu, 9 Sep 2004, Andy Polyakov wrote:
> >> +#ifdef __DJGPP__
> >> +int RAND_poll(void)
> >> +{
> >> + for (i = 0; i < sizeof(buf); i++) {
> >> + srand(rawclock() + i);
> >> + ...
> >
> > The problem is that value returned by rawclock() will most likely remain
> > constant for every invocation of the routine in question. Or rather that
> > probability of its changing is diminishingly low even for elder CPU, as
> > it has enough time for limited number of trivial arithmetic operations.
> > Essentially it's meaningless to filter the value returned by rawclock()
> > through [s]rand[om] as it won't *add* any entropy. There is a number of
> > other things one can do. If you run at privilege level 0 and on Pentium
> > or better you have the option to time hlt instruction, e.g.:
> >
> > rdtsc; mov %eax,%ecx; hlt; rdtsc; sub %ecx,%eax.
>
> There is new OPENSSL_instrument_halt() implemented in HEAD, which does
> the above and returns 0 if it was not appropriate to instrument halt.
> Preliminary tests show that this seems to be the best candidate for
> providing *some* entropy. It should be noted however that even under
> MS-DOS, running at privilege level 0 doesn't seem to be wide-spread
> option. At least the default DPMI driver provided with DJGPP is not
> privileged. There are replacements provided, CWSDPR0.EXE and PMODE/DJ,
> but who uses them?
No one is using CWSDPRO or PMODE/DJ except for special applications,
and I don't believe that these apply at all if running in a "DOS box"
under windows.
As I have mentioned, I am neither a programmer nor a cryptographer,
and I feel I am out of my depth in the discussion about getting
adequate entropy under plain DOS. I do see that the entropy gotten
from the timer alone is probably inadequate. It seems that a part of
the problem is that DOS doesn't have any device to collect entropy.
I have just found out that there is a DOS port of /dev/random that
can be installed to generate true random data on DOS. I installed
it on my machine and then compiled openssl with DEVRANDOM set
to "/dev/urandom$", which is the device that gets installed.
(Because of the "$" at the end of the name, the makefile actually
says DEVRANDOM="\"/dev/urandom$$$$$$$$\""). Openssl then compiles
and passes "make test". I don't think I can tell from looking at
the code whether this is actually providing adequate randomness.
Perhaps someone (? Andy) can take a look at the code for the DOS
/dev/urandom|/dev/random port and see if it is something that could
be reasonably used. The code is GPL'd, so it couldn't be included in
OpenSSL without getting the author to modify the license, but it should be
OK to install the binary on a DOS machine to provide /dev/random and
/dev/urandom equivalents.
The DOS port of /dev/random does not appear to be
actively developed at this time. It was written by Robert Rothenberg
Walking-Owl and can be found at
"http://www.funet.fi/pub/crypt/random/noise063.zip";.
I just compiled the 0.9.8 snapshot from 20040912 without the "386"
switch. It compiles OK, with warnings again from the
crypt/engine/eng_padlock.c file. In the "padlock_aes_cipher", the fourth
argument was made "size_t" instead of "unsigned int". This causes the
following warnings when compiling with gcc:
eng_padlock.c:676: warning: initialization from incompatible pointer type
eng_padlock.c:677: warning: initialization from incompatible pointer type
eng_padlock.c:678: warning: initialization from incompatible
pointer type
eng_padlock.c:679: warning: initialization from incompatible pointer type
eng_padlock.c:681: warning: initialization from incompatible pointer type
eng_padlock.c:682: warning: initialization from incompatible pointer type
eng_padlock.c:683: warning: initialization from incompatible pointer type
eng_padlock.c:684: warning: initialization from incompatible pointer type
eng_padlock.c:686: warning: initialization from incompatible pointer type
eng_padlock.c:687: warning: initialization from incompatible pointer type
eng_padlock.c:688: warning: initialization from incompatible pointer type
eng_padlock.c:689: warning: initialization from incompatible pointer type
I am sorry that I can't comment more meaningfully on the underlying
problem regarding obtaining randomness on DOS. I now see that my
previous patch for RAND_poll doesn't do what I intended. I'll be happy
to test any proposed code as best as I can, but I doubt that I will be
able to make any new contributions here.
Doug
--
Doug Kaufman
Internet: [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
