DOS ain't dead

bencollver 08.05.2024, 07:03	GnuPG 1.4.23 for DOS (Announce) Post reply
	GnuPG is a complete and free implementation of the OpenPGP standard as defined by RFC4880. GnuPG allows you to encrypt and sign your data and communications. Built with DJGPP and lightly tested on DOSBox and FreeDOS. See doc/djgpp.txt for installation instructions and limitations. https://archive.org/details/gnupg-1.4.23-for-dos gopher://tilde.pink/1/~bencollver/files/dos386/util/gnupg/

rosegondon

C:\DOS,
08.05.2024, 11:09

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> GnuPG is a complete and free implementation of the OpenPGP standard as
> defined by RFC4880. GnuPG allows you to encrypt and sign your data and
> communications.
> Built with DJGPP and lightly tested on DOSBox and FreeDOS. See
> doc/djgpp.txt for installation instructions and limitations.

This build fails to generate keypair under FreeDOS 1.2 and MS-DOS 6.22. Hangs when accessing NOISE device. Diff file contains both "/dev/urandom$" and "/dev/urandom" names, while NOISE.SYS exposes only names with dollar sign, i.e. "/dev/random$" and /dev/urandom$".

I checked using commands:

if exist /dev/urandom echo Found "/dev/urandom"
if exist /dev/urandom$ echo Found "/dev/urandom$"

Only "/dev/urandom$" was found.

---
echo g=ffff:0|debug>nul

bencollver

08.05.2024, 16:48

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

> This build fails to generate keypair under FreeDOS 1.2 and MS-DOS 6.22.
> Hangs when accessing NOISE device. Diff file contains both "/dev/urandom$"
> and "/dev/urandom" names, while NOISE.SYS exposes only names with dollar
> sign, i.e. "/dev/random$" and /dev/urandom$".

The diff says:
+ NAME_OF_DEV_URANDOM='/dev/urandom$' ... -NAME_OF_DEV_URANDOM="/dev/urandom" ... +NAME_OF_DEV_URANDOM=${NAME_OF_DEV_URANDOM:-"/dev/urandom"}

This means if you configure it to build with DJGPP, as i did, then it will use /dev/urandom$. Otherwise, by the time it reaches that last line, NAME_OF_DEV_URANDOM will be empty and unset, and for non-DJGPP builds it will fall back to using /dev/urandom.

If you try to generate a key without the NOISE driver, it will throw an error saying that it could not open /dev/urandom$ This leads me to believe that it is indeed using /dev/urandom$

I generated RSA keys on FreeDOS 1.3. It appeared to hang, i assumed because DJGPP severely buffers output, introducing a lot of delay. After a minute or so, it shows the output while it collects randomness, and then generates a key, which i used to sign, encrypt, and decrypt files.

I will test it on MS-DOS 6.22 and report back. I'll also see whether i can eliminate the delayed console output.

rosegondon

C:\DOS,
08.05.2024, 18:20

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> I generated RSA keys on FreeDOS 1.3. It appeared to hang, i assumed
> because DJGPP severely buffers output, introducing a lot of delay. After a
> minute or so, it shows the output while it collects randomness, and then
> generates a key, which i used to sign, encrypt, and decrypt files.

Just made another test on DOS 6.22. 7+ minutes of waiting and still no move.

---
echo g=ffff:0|debug>nul

bencollver

08.05.2024, 22:19

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

I reproduced the problem in MS-DOS. While generating a key pair, i get as far as entering the passphrase twice. Then it freezes. Printf() debugging shows the following "backtrace."

passphrase_to_dek()
hash_passphrase()
randomize_buffer()
get_random_bits()
read_pool()
random_poll()
read_random_source()
getfnc_gather_random()
rndlinux_gather_random()

There's a do/while loop in rndlinux_gather_random() that never ends on MS-DOS. Every read from /dev/urandom$ returns 0 bytes and no errors.

I can read urandom$ from the command line, so the problem must have something to do with how GPG / DJGPP is reading it. I will troubleshoot this further when i find the time.

bencollver 09.05.2024, 05:18 (edited by bencollver, 09.05.2024, 06:40) @ bencollver	GnuPG 1.4.23 for DOS Post reply
	I posted an update in gpg14b.zip. Changes: * Use unbuffered stdout to eliminate delayed output. * Open NOISE device in binary mode * Fix LFN issues in file locking code Key generation consistently succeeds on MS-DOS 6.22 after i made the following changes: * in CONFIG.SYS use DEVICE=NOISE386.SYS /d * in AUTOEXEC.BAT, REM SMARTDRV.EXE to disable the disk cache

rosegondon

C:\DOS,
09.05.2024, 12:48

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> I posted an update in gpg14b.zip.
> * in CONFIG.SYS use DEVICE=NOISE386.SYS /d
> * in AUTOEXEC.BAT, REM SMARTDRV.EXE to disable the disk cache

Repeated test with the specified config.
GPG hangs again, repeating key generating message twice:

[image]

---
echo g=ffff:0|debug>nul

bencollver

09.05.2024, 16:32

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

Thanks for trying again and posting your screenshot. Is this MS-DOS 6.22? What's it running on?

Yesterday i tinkered with sample.c and sample.exe from the NOISE driver. I learned that /dev/random$ will effectively block indefinitely after the NOISE driver entropy pool becomes empty. It won't generate random bytes unless it has sufficient entropy. The documentation says that the NOISE driver's entropy estimation is relatively conservative.

Yesterday i was able to work around it by adding the /d flag to include disk timing data into the entropy pool. I generated about a half dozen or so RSA keypairs on MS-DOS 6.22 running in qemu, and it rapidly succeeded every time.

From your screenshot, my guess is that GPG was able to read enough random bytes to generate the first half of the key pair, and it blocked in the second half because the NOISE driver ran out of entropy.

The documentation states that you can collect entropy ahead of time. This is just speculation on my part: Maybe it would help to do something disk intensive before generating a keypair? The most disk intensive thing i can think of is compiling a big program with DJGPP. :-)

rosegondon

C:\DOS,
09.05.2024, 17:11

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> Thanks for trying again and posting your screenshot. Is this MS-DOS 6.22?
> What's it running on?

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

> The documentation states that you can collect entropy ahead of time. This
> is just speculation on my part: Maybe it would help to do something disk
> intensive before generating a keypair? The most disk intensive thing i can
> think of is compiling a big program with DJGPP. :-)

During every boot small program I wrote replenishes NOISE.SYS pool with fresh entropy. Also before generating keys I did a test using another diagnostic tool for NOISE.SYS:

[image]

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

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?

---
echo g=ffff:0|debug>nul

bencollver

09.05.2024, 19:30

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

> 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.

rosegondon

C:\DOS,
09.05.2024, 21:08

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

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

All default. My QEMU-based DOS 6.22 is started just like that:

qemu-system-i386 -hda dos.img

> > 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.

This is a tool I wrote in Turbo Pascal as a showcase for my NOISE.SYS API
library: https://pastebin.com/raw/D38aUPYi

> 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.

This is a good idea. I would like to test relevant GPG build.

> 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.

I always use 4096-bits or larger RSA keys.

---
echo g=ffff:0|debug>nul

bencollver

09.05.2024, 23:32

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

I think it worked for me because i was generating 1024 bit keys. When i tried to generate a 4096 bit keypair on MS-DOS, it failed, presumably because it was blocking on an empty entropy pool in the NOISE device.

I posted gpg14c.zip which honors the RNG_DEVICE environment variable. If you set RNG_DEVICE=/dev/urandom$ then GnuPG will use that when it generates keys. This will guarantee that it never blocks on an empty entropy pool, but i will reiterate that the documentation warns against doing this.

From a crypto standpoint it would probably be better to explore the other entropy sources, which involve tweaking and rebuilding NOISE. I will look into that and also look into building your Turbo Pascal source code when i find the time. Thanks for the source code.

rosegondon

C:\DOS,
10.05.2024, 19:10

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> I posted gpg14c.zip which honors the RNG_DEVICE environment variable. If
> you set RNG_DEVICE=/dev/urandom$ then GnuPG will use that when it generates
> keys. This will guarantee that it never blocks on an empty entropy pool,
> but i will reiterate that the documentation warns against doing this.

Thank you, I will test it ASAP.

> From a crypto standpoint it would probably be better to explore the other
> entropy sources, which involve tweaking and rebuilding NOISE. I will look
> into that and also look into building your Turbo Pascal source code when i
> find the time. Thanks for the source code.

I have few ideas for totally new NOISE.SYS engine:
- Implement Schneier's Fortuna (it has very strong security guarantee).
- Implement HMAC-DRBG (much simpler implementation).
- Or hybrid of both schemes: https://www.cryptosys.net/rng_algorithms.html

---
echo g=ffff:0|debug>nul

RayeR

CZ,
14.05.2024, 20:49

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

> I have few ideas for totally new NOISE.SYS engine:
> - Implement Schneier's Fortuna (it has very strong security guarantee).
> - Implement HMAC-DRBG (much simpler implementation).
> - Or hybrid of both schemes: https://www.cryptosys.net/rng_algorithms.html

BTW how about to use RDRAND on modern CPUs? If it's already used then ignore it, I didn't check inside...

https://en.wikipedia.org/wiki/RDRAND

---
DOS gives me freedom to unlimited HW access.

bencollver

14.05.2024, 22:36

@ RayeR

GnuPG 1.4.23 for DOS

Post reply

> BTW how about to use RDRAND on modern CPUs? If it's already used then
> ignore it, I didn't check inside...
>
> https://en.wikipedia.org/wiki/RDRAND

I don't believe NOISE.SYS nor GnuPG 1.4.23 are using RDRAND. If i understand it correctly, RDRAND ought to be easy to add to NOISE.SYS. I welcome a patch to do that. :-)

Interesting quote on that Wikipedia page: "Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea."

As i understand it, NOISE.SYS already mixes multiple sources of entropy. It might help to "backport" the RDRAND security fix from Linux 3.13.

RayeR

CZ,
14.05.2024, 23:55

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

Yes, it's always good to combine more entropy sources. Imagine that instruction RDRAND can be modified via CPU microcode update to return a constant known value if e.g. NSA decide to deploy such patch via windows update automatically :) Probably cannot be affected on a pure DOS machine but once it has multiboot...

---
DOS gives me freedom to unlimited HW access.

Rugxulo

Usono,
15.05.2024, 06:21

@ RayeR

NSA is coming to get you (and your cat)!

Post reply

> Imagine ... NSA decide to deploy such patch via windows update
> automatically :)

"Imagine", so totally based upon reality. /s

* they have unlimited power (and skills, money, time)
* they have the motivation (war?)
* there is a perceived benefit (that outweighs negative consequences)
* they have no morals and no reservations about bad actions

Or maybe they're just drunk.

I don't think it's reasonable to live based upon fear, especially the idea that others can do "anything". Most people are pathetic, hardly evil supervillains.

Having said that, it may be wise to avoid obvious flaws.

rosegondon

C:\DOS,
15.05.2024, 11:48

@ Rugxulo

NSA is coming to get you (and your cat)!

Post reply

> > Imagine ... NSA decide to deploy such patch via windows update
> > automatically :)
>
> "Imagine", so totally based upon reality. /s
>
> * they have unlimited power (and skills, money, time)
> * they have the motivation (war?)
> * there is a perceived benefit (that outweighs negative consequences)
> * they have no morals and no reservations about bad actions
>
> Or maybe they're just drunk.
>
> I don't think it's reasonable to live based upon fear, especially the idea
> that others can do "anything". Most people are pathetic, hardly evil
> supervillains.

Pathetic or villainous people - in any case my data and privacy are at risk.

Everything that Snowden revealed was called "paranoia" and "conspiracy theory" before.
Now even your car is recording your sex life: https://foundation.mozilla.org/en/blog/privacy-nig...ford-volkswagen-and-toyota-flunks-privacy-test/

Outlook sends your passwords to Microsoft cloud, among other data send to "interested third parties":
https://proton.me/blog/outlook-is-microsofts-new-data-collection-service

And knowing that FreeBSD banned RDRAND, I wouldn't use it under DOS, too:
https://arstechnica.com/information-technology/201...-vias-chip-based-crypto-freebsd-developers-say/

---
echo g=ffff:0|debug>nul

RayeR

CZ,
15.05.2024, 17:40

@ rosegondon

NSA is coming to get you (and your cat)!

Post reply

OK, I conclude that RDRAND was not a smart idea. It's handy but only on newer CPUs and cannot be trusted. In fact, cybersecurity on a common modern x86 platform is just parody as you don't have neither HW nor FW under your control. There are too much proprietary stuff like CPU microcode, Management Engine, SMI handler that has higher priority (or out of band) over the OS/applications and cannot be audited.

This is why some attempts like Librem was created
https://www.crowdsupply.com/purism/
But it's still not enough. A real secure system could be based on openHW CPU like RISC V or use some openHW CryptoChip - I read that one bitcoin company from our country Satoshilabs/Tropic square started developing its own cryptochip for HW BTC trezor (wallet)
https://satoshilabs.com/news/trezor-takes-control-of-its-silicon-chip-supply-chain
This could be a way...

And yes I'm aware about GPS telematics units in new vehicles as it's close to my job (I read about maybe 10 years ago it's planned to enforce this in every new vehicle)...

---
DOS gives me freedom to unlimited HW access.

rosegondon

C:\DOS,
10.05.2024, 19:30

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

---
echo g=ffff:0|debug>nul

bencollver

11.05.2024, 20:44

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

> Quick observation after first tests: DOS GPG buils fails often with file
> creation, because of multiple-extension filenames it creates.
>
> For example, when I run
>
> gpg --clearsign mytext.txt
>
> GPG tries to write to mytext.txt.asc and fails. Every time I need to use
> "--output" directive i commandline.

Does it help to use the --mangle-dos-filenames option? If so, then i could default to enabling that option.

bencollver

13.05.2024, 07:12
(edited by bencollver, 13.05.2024, 07:31)

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

I posted gpg14e.zip, which has the following changes.

* Enable --mangle-dos-filename option by default, which fixes --clearsign
* Include custom NOISE.SYS with larger entropy pool
* Include chknois.com to diagnose NOISE.SYS

I used nomyso.pl to convert the NOISE.SYS sources from TASM to NASM syntax. It required a bunch of hand correction. It seems to work okay, but no guarantees because i am not very confident with NASM and TASM.

I love your ideas for creating a replacement NOISE.SYS driver. If you make it, i would be happy to help test it.

bencollver 14.05.2024, 01:31 @ bencollver	GnuPG 1.4.23 for DOS Post reply
	I posted gpg14f.zip, which is patched to mitigate CVE-2019-14855 * Default to SHA256 instead of SHA1 * Add SHA1 to the weak digest list It is still possible to verify old signatures using the --allow-weak-digest-algos option.

rosegondon

C:\DOS,
14.05.2024, 09:53

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> I posted gpg14f.zip, which is patched to mitigate CVE-2019-14855
>
> * Default to SHA256 instead of SHA1
> * Add SHA1 to the weak digest list
>
> It is still possible to verify old signatures using the
> --allow-weak-digest-algos option.

May I interest you in pgp263iamulti06.zip? This project, ended by premature death of its developer, was aiming to "make PGP great again" by implementing more contemporary primitives and allowing for larger key sizes.

http://lukatela.com/hrvoje/pgp263iamulti06/download.html

In my humble opinion, this version should be still developed, providing users with secure encryption on secure DOS platform.

---
echo g=ffff:0|debug>nul

bencollver 14.05.2024, 17:04 @ rosegondon	GnuPG 1.4.23 for DOS Post reply
	Thanks! I like that pgp263iammulti06 has a real-mode DOS build. I'd love to see someone take over its development, perhaps configuring it for inclusion in FreeDOS and building it with Watcom. By the way, how did the latest build of GnuPG work for you? Are you able to generate keys and clearsign files now?

rosegondon

C:\DOS,
14.05.2024, 18:33

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> By the way, how did the latest build of GnuPG work for you? Are you able
> to generate keys and clearsign files now?

Yes, everything worked perfectly. Thank you for empowering DOS users with compatible GPG build.

---
echo g=ffff:0|debug>nul

rosegondon

C:\DOS,
15.05.2024, 11:43

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> Thanks! I like that pgp263iammulti06 has a real-mode DOS build. I'd love
> to see someone take over its development, perhaps configuring it for
> inclusion in FreeDOS and building it with Watcom.
>
> By the way, how did the latest build of GnuPG work for you? Are you able
> to generate keys and clearsign files now?

BTW, how configuration file "gpg.conf" should be named under DOS? "gpg.con"?

---
echo g=ffff:0|debug>nul

bencollver 15.05.2024, 17:00 @ rosegondon	GnuPG 1.4.23 for DOS Post reply
	> BTW, how configuration file "gpg.conf" should be named under DOS? > "gpg.con"? Correct For example on MS-DOS 6.22 if you type: C:\gnupg>COPY CON gpg.conf dry-run ^Z It will create gpg.con and gpg.exe will use that file for its options. If you want to use a different name, then do something like: gpg --options c:/gnupg/options.cfg

rosegondon

C:\DOS,
16.05.2024, 07:13

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> By the way, how did the latest build of GnuPG work for you? Are you able
> to generate keys and clearsign files now?

gpg14f hangs when just executed without any parameters.
It hangs after standard prompt "Go and type your message".

Also, for some reason, my preferences from "gpg.con" are ignored, when generating keys. Keys are generated with default preferences.

---
echo g=ffff:0|debug>nul

bencollver

17.05.2024, 02:20

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

> gpg14f hangs when just executed without any parameters.
> It hangs after standard prompt "Go and type your message".
>
> Also, for some reason, my preferences from "gpg.con" are ignored, when
> generating keys. Keys are generated with default preferences.

Thanks for the heads up. I reproduced the problem where gpg hangs when executed without any parameters. I will troubleshoot this when i find the time.

I was not able to reproduce the problem where the preferences are ignored.

What is your GNUPGHOME variable set to?

What is the path to gpg.con?

Would you be willing to post the contents of gpg.con, plus the type of key you are generating and how the result differs from what you expected?

Thanks!

rosegondon

C:\DOS,
17.05.2024, 07:31

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> I was not able to reproduce the problem where the preferences are ignored.
>
> What is your GNUPGHOME variable set to?
>
> What is the path to gpg.con?

GNUPGHOME is not set.

File "gpg.con" has two copies: one in folder with GPG.EXE (which is NOT in C:\GNUPG) and one in C:\GNUPG folder, forcibly recreated by GPG if not existing.

I was using commandline directive "--options gpg.con" when running GPG from its folder.

---
echo g=ffff:0|debug>nul

bencollver

17.05.2024, 16:14

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

> File "gpg.con" has two copies: one in folder with GPG.EXE (which is NOT in
> C:\GNUPG) and one in C:\GNUPG folder, forcibly recreated by GPG if not
> existing.
>
> I was using commandline directive "--options gpg.con" when running GPG from
> its folder.

I was not able to reproduce this problem. When i run C:\GPG\GPG.EXE, it does not recreate C:\GNUPG\gpg.con.

I created two configuration files with different cert-digest-algo settings, one in C:\GNUPG\gpg.con and the other in C:\GPG\gpg.con.

When i run GPG.EXE --gen-key, it creates a key using the digest algo specified in C:\GNUPG\gpg.con

When i run GPG.EXE --options gpg.con --gen-key, it creates a key using the digest algo specified in C:\GPG\gpg.con

Which options are you using in gpg.con and how do the results differ from what you expected?

rosegondon

C:\DOS,
17.05.2024, 18:38
(edited by rosegondon, 17.05.2024, 19:13)

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> Which options are you using in gpg.con and how do the results differ from
> what you expected?

My two copies of "gpg.con" are identical (one in GPG folder with program and another in C:\GNUPG with keyfiles).
The options ignored are really all options in these files, which are mostly the definition of preferred encryption and hash algorithms in order of preference.

personal-cipher-preferences AES256 CAMELLIA256 TWOFISH personal-digest-preferences SHA512 personal-compress-preferences ZLIB ZIP digest-algo SHA512 no-random-seed-file no-emit-version no-version no-comments throw-keyids utf8-strings

Moreover, every time (tried three times) GPG generates keys with dates in the future:

[image]

---
echo g=ffff:0|debug>nul

bencollver 17.05.2024, 19:22 @ rosegondon	GnuPG 1.4.23 for DOS Post reply
	Thanks for your gpg.con contents. How do you test whether they are being ignored? > Moreover, every time (tried three times) GPG generates keys with dates in > the future: Before generating keys, try: set TZ=PST8PDT

rosegondon

C:\DOS,
17.05.2024, 22:03

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> Thanks for your gpg.con contents. How do you test whether they are being
> ignored?

gpg --edit-key
showpref

---
echo g=ffff:0|debug>nul

rosegondon

C:\DOS,
17.05.2024, 22:17

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> Thanks for your gpg.con contents. How do you test whether they are being
> ignored?
>
> > Moreover, every time (tried three times) GPG generates keys with dates
> in
> > the future:
>
> Before generating keys, try:
>
> set TZ=PST8PDT

But why key creation dates jump randomly? This is not constant shift in date.
I never saw such GPG behavior.

---
echo g=ffff:0|debug>nul

bencollver

19.05.2024, 05:53

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

> But why key creation dates jump randomly? This is not constant shift in
> date.
> I never saw such GPG behavior.

It was DJGPP's fault. GPG gets the key creation timestamp from time(2). On DJGPP, time(2) uses gettimeofday(2), which in turn uses mktime(3), which relies on the TZ environment variable in order to produce correct results. When the TZ variable is invalid or unset, time(2) intermittently gives incorrect results. I am not sure why it is intermittent. The timestamp may be correct, or it may be set weeks in the future. If i generated a key with a creation date weeks in the future, and then ran "gpg --list-keys" several times in a row, then any given time it might give a warning, and the next time it might not.

I found that i could work around this using:

SET TZ=DOS0

DOS0 is not a real time zone, but it is valid POSIX TZ extended format. The "DOS" part is just a name and the "0" part means zero hours offset from UTC. This assumes that the hardware clock is set to UTC. A normal DOS system has the hardware clock set to local time, not UTC. In my case i have:

SET TZ=PST8PDT

rosegondon

C:\DOS,
17.05.2024, 22:31

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> Thanks for your gpg.con contents. How do you test whether they are being
> ignored?
>
> > Moreover, every time (tried three times) GPG generates keys with dates
> in
> > the future:
>
> Before generating keys, try:
>
> set TZ=PST8PDT

I deleted all keyrings. I deleted gpg.con and recreated it manually typing from memory (meanwhile I detected that because of previous copy-pasting, my gpg.con file had different EOL types, both Linux and Windows ones). Then I set TZ to the value you suggested. After generating new keys, all keys had the embedded options I expected and proper creation date.

The only weird thing remaining is hanging when GPG is started without any parameters.

---
echo g=ffff:0|debug>nul

bencollver

19.05.2024, 05:10

@ rosegondon

GnuPG 1.4.23 for DOS

Post reply

> The only weird thing remaining is hanging when GPG is started without any
> parameters.

I posted gpg14g.zip with the following changes:

* Don't open console in binary mode. This fixes running gpg without args.
* Note that the TZ environment variable must be set.
* Note the default configuration file name.
* Note that this file needs to be in DOS format.
* Note that NOISE.SYS needs the /o flag on FreeDOS.

Thanks for your testing and problem reports!

rosegondon

C:\DOS,
20.05.2024, 21:04

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

> I posted gpg14g.zip with the following changes:
>
> * Don't open console in binary mode. This fixes running gpg without args.
> * Note that the TZ environment variable must be set.
> * Note the default configuration file name.
> * Note that this file needs to be in DOS format.
> * Note that NOISE.SYS needs the /o flag on FreeDOS.
>
> Thanks for your testing and problem reports!

Could you be so kind and add detached GPG signature to the files published
and also the diff files for source code, for interested developers?

---
echo g=ffff:0|debug>nul

bencollver 20.05.2024, 21:53 @ rosegondon	GnuPG 1.4.23 for DOS Post reply
	> Could you be so kind and add detached GPG signature to the files published > and also the diff files for source code, for interested developers? Sure thing! You can find the detached GPG signature in gpg14g.asc using the gopher link. You can find the diff file in gpg14g.zip under src/gnupg-djgpp.diff

bencollver

31.05.2024, 00:17

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

I wanted to spot check the quality of the random numbers generated by NOISE.SYS

I read that:

> Statistically testing a PRNG requires quite a lot (10 or even 100 GB)...

> All tests of RNGs are based on a "null hypothesis", meaning if they
> fail, they show the RNG may be flawed. But if they pass, it does
> not mean it is good.

Keeping these in mind, i decided that ENT was good enough for me.

ENT home page
https://www.fourmilab.ch/random/

ENT DJGPP build
gopher://tilde.pink/9/~bencollver/files/dos386/util/gnupg/ent14.zip

Comparing the resulting Chi-square percentages:

* Linux has 93.44% (almost suspect) and
* NOISE.SYS has 97.88% (suspect).

This seems to indicate a problem in NOISE.SYS.
I'm a hacker not a cryptographer, so i don't know how to fix it.

Linux
=====
$ dd if=/dev/random of=linux.dat bs=1024 count=1024
$ ent <linux.dat
Entropy = 7.999848 bits per byte. Optimum compression would reduce the size of this 1048576 byte file by 0 percent. Chi square distribution for 1048576 samples is 221.79, and randomly would exceed this value 93.44 percent of the times. Arithmetic mean value of data bytes is 127.4089 (127.5 = random). Monte Carlo value for Pi is 3.143658232 (error 0.07 percent). Serial correlation coefficient is 0.001572 (totally uncorrelated = 0.0).

FreeDOS
=======
C:\NOISE>busy.bat
C:\NOISE>sample.exe noise.dat 1048576 -ar

Repeat this hundreds of times until noise.dat reaches the desired size.

C:\ENT>ent <C:\NOISE\NOISE.DAT
Entropy = 7.999855 bits per byte. Optimum compression would reduce the size of this 1048576 byte file by 0 percent. Chi square distribution for 1048576 samples is 211.27, and randomly would exceed this value 97.88 percent of the times. Arithmetic mean value of data bytes is 127.5550 (127.5 = random). Monte Carlo value for Pi is 3.146267495 (error 0.15 percent). Serial correlation coefficient is 0.000964 (totally uncorrelated = 0.0).

bencollver

31.05.2024, 02:04

@ bencollver

GnuPG 1.4.23 for DOS

Post reply

Re-running the test, i found that the Chi-square percentages vary wildly.
This makes the results seem less meaningful to me.

Even on Linux, with enough tests, i was able to get a result of 99.73%.
This goes beyond "suspect" and into the "not random" range.

Apparently 1 MB is too small a sample set.

NOISE.SYS is difficult to analyze because it doesn't make it easy to
collect tens or hundreds of gigabytes of random data.

GnuPG 1.4.23 for DOS (Announce)

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

NSA is coming to get you (and your cat)!

NSA is coming to get you (and your cat)!

NSA is coming to get you (and your cat)!

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS

GnuPG 1.4.23 for DOS