Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

GnuPG 1.4.23 for DOS (Announce)

posted by bencollver Homepage, 09.05.2024, 19:30

> I made tests on QEMU and some generic PC from 90s frem my collection. In
> both instances generating failed.

Interesting that we are getting different results in qemu. Would you be willing to post your qemu options?

> So I am sure that pool was full when GPG started.

Thanks for that information. Do you recall where you got chknois? I searched and the search engine gave me results for chkdsk and chinois.

> URANDOM$ never blocks because it is more or less a CSPRNG using entropy
> pool as its internal state. It will not delete entropy used. RANDOM$
> deletes used entropy and blocks, when pool becomes empty. So if your GPG
> build is using URANDOM$, it should not hang. So something else is wonky
> here. Maybe there is some other check of pool entropy which will stop the
> generating process when there is not enough entropy?

The gnupg code uses both URANDOM$ and RANDOM$, depending on the context. The rndlinux_gather_random() function has a "level" argument. If the level is 2 or above, then it uses RANDOM$ instead of URANDOM$. It does the same thing on Linux, except it uses /dev/random instead of /dev/urandom.

The code does use select() to check whether there are bytes available to be read, but on with DOS and the NOISE driver, select() ALWAYS reports that there are bytes available to be read, even if there aren't any. Gnupg endlessly reads /dev/random$, getting 0 bytes every time and no errors.

Both the gnupg and NOISE documentation say NOT to use /dev/urandom and URANDOM$ for private key generation, because it is effectively a pseudo-random number generator, and not cryptographically strong.

One possible workaround would be for me to patch gnupg to honor the RNG_DEVICE environment variable so that end users can set it to /dev/urandom$ even though the documentation explicitly says NOT to do so. This would guarantee key generation in spite of inadequate entropy.

p.s.

Which type of key are you generating and how many bits? I don't know for sure, but it seems to me that 512 bytes (4096 bits) ought to be enough random data to generate a 1024 bit RSA key.

 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 125 users online (0 registered, 125 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum