On Tue, 13 Jan 2026 15:44, Rat Bag via Gnupg-users wrote:
> Is using gpg 1.4 on an "air-gaped" computer to generate RSA 4096 keys
> and encrypting files/messages to owners of such keys still considered
> safe?
I'm specifically using GPG 1.4 [1] and I have recently instructed someone
with vintage system (Windows XP) to install GPG 1.4 because software
he uses doesn't work with newer GPG series; so I have some pointers to give.
> encrypting files/messages to owners of such keys still considered safe?
Bar secret zero-day exploits we didn't know of, using that setup
to sign/verify/encrypt/decrypt stuff are generally okay.
Software do not rot like milk and meat do; old software means it's
time-tested, and timeless software that work through ages are good software.
In my eyes, ideal version of software is the version that is good enough
for me to continue using it for the rest of my life.
Also, old software means it was authored based on system requirements of
the past (not just CPU, RAM, and storage requirement; but also compatibility
with data format/ABI/API of older software/OS from that era too).
If you have vintage systems, air-gapped or not, using old era-appropriate
software is going to matter in a lot of cases-- as long as such software
and version could still do what you need it to do.
And when GPG got ported to "ancient" systems like, say, DOS/DJGPP;
GPG 1.x is going to be the one that could get ported, not 2.x. [2]
> to generate RSA 4096 keys
This specific part is where few pitfalls exists
and you have to watch out for. (For the record: these don't affect
migrated keys generated from GPG 2.x setups that were imported to GPG 1.4)
These could easily be worked around of course, but you need to know
that these pitfalls exist first, in order to apply such workarounds...
8<-----
First pitfall is the issue of keypair/user-ID binding certificate signature's
hash algorithm. When you make GPG generate a keypair, it doesn't just
calculate private and public key for you; it also do one self-signature
on the key content, and another one which binds your user ID (name+email)
declaration to the keypair...
The problem being: GPG 1.4 was released in the days and age when SHA-1
hash algorithm was still considered cryptographically-secure
(marginally secure, but nonetheless still secure back then),
so it will sign on SHA-1 hash to certify your newly-generated key
and its attached user ID _by default_.
And as you already know, you really don't want it to do that in 2026. [4]
Mr. Koch had also kindly hinted to me (in [3]) that current GPG 2.x
also rejects SHA-1 hash-based binding signature it sees in any key
created after 19-Jan-2019.
Note: This issue is not readily-apparent to users because this
binding signature information is not shown in `gpg --list-keys`
nor `gpg --edit-key` interface; and could only be seen
when you do `gpg --list-packets` on the exported key file. [5]
Indeed, GPG 1.4 *can* generate key with self-signature + user ID certified
via other hash algorithms that are still considered secure today,
including SHA-256 and above; but you will have to explicitly
configure it to do so. (And since you're going to use 4096-bit RSA already,
you might want to go use SHA-512 hash for this; just in case)
^ But the important part that you have to keep in mind is:
you *MUST* configure it so *BEFORE* generating a key with such setup.
Else, you would end up in quite a predicament indeed. [6]
You can configure GPG 1.4 to use SHA-512 hash in key/user-ID
binding signatures, by adding the following line to your
`~/.gnupg/gpg.conf` file:
cert-digest-algo SHA512
But don't generate your key right after you added this yet, because...
8<-----
The second pitfall is default personal cryptographic algorithm priority list
that GPG 1.4 assigns by default to your newly-generated keypair.
Again, the list back in the days was not ideal in 2026 for obvious reasons.
^ This pitfall is not so severe as the first one, because you
can always correct it after the fact via regular `gpg --edit-key`.
You can configure GPG 1.4 to use a priority list that is as close
as possible to the one that current GPG 2.x gives to a new RSA-4096 key,
by adding the following line to your `~/.gnupg/gpg.conf` file:
default-preference-list AES256 AES192 AES SHA512 SHA384 SHA256 SHA224 ZLIB
BZIP2 ZIP Uncompressed MDC no-ks-modify
^ Side note that when you used `showpref` in `gpg --edit-key` interface
on a keypair generated _after_ this configuration change, you would
still see "3DES" appearing in Cipher line as well as "SHA1" in Digest line;
but as the *last* item. They are there because the relevant standard
(thus interoperability consideration) require these two
to be _implicitly_ included (thus on-display); [8] but they will not
actually be used because:
A. Virtually every implementations out there implement better algorithms
which will be picked first in face of a good in-key priority list
like this.
B. The actual preferences list published in the public key generated
under this configuration would actually *not* include the
SHA-1 hash algorithm. (See the explanation of second dump output of [5])
Now that you know how, go configure it, make keys
(maybe also verify by exporting and dumping too [5]), then cipher away;
and cheers for old computers everyday.
Regards,
Nutchanon Wetchasit
GnuPG: 1.4.12 (Debian)
System: Debian GNU/Linux 7.0 "Wheezy" i386
-----
[1] Because A. I use vintage system (I couldn't get current GPG 2.x
to compile on my system; will get on to report/ask about that later)
and B. I have some use for GPG (symmetric mode) in low-trust environment
where it _must_ run *without* using agent or `~/.gnupg` directory
whatsoever (not even a temporary one)-- which GPG 2.x will definitely
not do.
[2] GPG 2.x would not work on DOS anyhow, because it needs a second
agent process (and a third... keystore daemon?) to be running
simultaneously; which is simply not possible under DOS.
As you already know, DOS is a single-tasking system.
And regarding GPG 1.x on DOS: yes, DOS/DJGPP port of GPG 1.4.23 exists.
https://archive.org/details/gnupg-1.4.23-for-dos
https://sourceforge.net/p/freedos/news/2024/05/gnupg-1423-for-dos/
As one of the people who have DOS in boot menu in 2026,
this is not of a mere novelty value.
[3] https://lists.gnupg.org/pipermail/gnupg-users/2024-November/067404.html
as a follow-up of:
https://lists.gnupg.org/pipermail/gnupg-users/2024-November/067403.html
[4] https://sha-mbles.github.io/
[5] For example, this is an output of `gpg --list-packet` of a
dummy public key *affected* by this SHA-1 binding signature issue:
> $ gpg --list-packets joe.asc
> :public key packet:
> version 4, algo 1, created 1768466208, expires 0
> pkey[0]: [4096 bits]
> pkey[1]: [17 bits]
> :user ID packet: "Joe Sixpack <[email protected]>"
> :signature packet: algo 1, keyid 41D386A2806A8257
> version 4, created 1768466208, md5len 0, sigclass 0x13
> digest algo 2, begin of digest 94 68
> hashed subpkt 2 len 4 (sig created 2026-01-15)
> hashed subpkt 27 len 1 (key flags: 03)
> hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
> hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
> hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
> hashed subpkt 30 len 1 (features: 01)
> hashed subpkt 23 len 1 (key server preferences: 80)
> subpkt 16 len 8 (issuer key ID 41D386A2806A8257)
> data: [4095 bits]
> :public sub key packet:
> version 4, algo 1, created 1768466208, expires 0
> pkey[0]: [4096 bits]
> pkey[1]: [17 bits]
> :signature packet: algo 1, keyid 41D386A2806A8257
> version 4, created 1768466208, md5len 0, sigclass 0x18
> digest algo 2, begin of digest 9b 63
> hashed subpkt 2 len 4 (sig created 2026-01-15)
> hashed subpkt 27 len 1 (key flags: 0C)
> subpkt 16 len 8 (issuer key ID 41D386A2806A8257)
> data: [4096 bits]
You would see that there are 2 signature packets (first for
signing user ID right above it, second for self-signing the public key
right above it). At the right of each ":signature packet:",
you'd see "algo 1" which is fine (1=RSA signature); but the second
under such section, you would also see "digest algo 2"--
which is *NOT* okay (2=signed on SHA-1 hash value).
A 4096-bit RSA key which is generated by GPG 1.4 _after_
applying configuration changes I suggested, would look like
the following instead...
> $ gpg --list-packets rod.asc
> :public key packet:
> version 4, algo 1, created 1768468694, expires 0
> pkey[0]: [4096 bits]
> pkey[1]: [17 bits]
> :user ID packet: "Rodney Retro <[email protected]>"
> :signature packet: algo 1, keyid 27B25A464AF65994
> version 4, created 1768468694, md5len 0, sigclass 0x13
> digest algo 10, begin of digest 2c 0b
> hashed subpkt 2 len 4 (sig created 2026-01-15)
> hashed subpkt 27 len 1 (key flags: 03)
> hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
> hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
> hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
> hashed subpkt 30 len 1 (features: 01)
> hashed subpkt 23 len 1 (key server preferences: 80)
> subpkt 16 len 8 (issuer key ID 27B25A464AF65994)
> data: [4095 bits]
> :public sub key packet:
> version 4, algo 1, created 1768468694, expires 0
> pkey[0]: [4096 bits]
> pkey[1]: [17 bits]
> :signature packet: algo 1, keyid 27B25A464AF65994
> version 4, created 1768468694, md5len 0, sigclass 0x18
> digest algo 10, begin of digest 43 5b
> hashed subpkt 2 len 4 (sig created 2026-01-15)
> hashed subpkt 27 len 1 (key flags: 0C)
> subpkt 16 len 8 (issuer key ID 27B25A464AF65994)
> data: [4095 bits]
You would now see that in this case, second line inside each
":signature packet:" section have "digest algo 10" (10=signed on SHA-512
hash value) which are now good for 2026+ uses.
Sharp-eyed readers would also notice that on the "pref-hash-algos" line,
number "2" (2=SHA-1 hash algorithm) is also now gone; though
on the "pref-sym-algos" line, number "2" (3=Triple-DES cipher)
still remains as the _least_-preferred cipher.
See second link on footnote [8] if you're curious about which number
represented which algorithm under each category.
[6] If you _already_ created the key without aforementioned configuration
entry, you cannot fix such affected keypair under GPG 1.4 unfortunately.
The GPG 2.x's trick of changing key expiration date which I heard
from out there (and Mr. Koch also re-mentioned to me in [3])
doesn't work under GPG 1.4: I've tested, it will simply re-sign with
the same algorithm already used in that part.
Adding new user ID followed by deleting old user ID there would only
fix the signature binding the user ID, but not the self-signature
on the key content.
The recourses you have in that scenario for now are either generating
a new keypair under correct GPG 1.4 configuration; or exporting that
(still-encrypted) private+public keypair using `gpg --export-secret-key`
and bring it to GPG 2.x setup, apply 2.x's expiry date change workaround,
export the fixed keypair out (using `gpg --export-secret-key` again),
remove original private+public keypair from GPG 1.4 setup [7],
then import the fixed private+public keypair back onto it.
I aim to post a patch (or at least, a formal report) on this mailing list
once I could pinpoint where in GPG 1.4 source code I could change
in order to make such solution work under this version.
[7] If you didn't remove the original keypair,
GPG 1.4 will just skip importing your fixed one and issue
"gpg: key SHORTKEYID: already in secret keyring" warning instead.
[8] https://dev.gnupg.org/T5020 (
https://web.archive.org/web/20251008192708/https://dev.gnupg.org/T5020 )
https://www.rfc-editor.org/rfc/rfc4880.html#section-9
_______________________________________________
Gnupg-users mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-users
