Gnupg cannot handle extremely large keys on 32 bit Linux

Charly Avital shavital at
Mon Apr 16 18:42:21 CEST 2007

Hash: SHA256

Alexander Feigl wrote the following on 4/16/07 6:15 PM:

> Can confirm this on x86-linux with libgcrypt 1.2.4 but the key is imported as 
> 0xB61454A3 here (Gentoo Linux). 
> Furthermore if I import the key with 1.4.x and use gpg --list-key with gnupg 
> 2.0.3, the command shows the correct key id. But as soon as anything touches 
> the key RING (not the key itself) using 2.0.3 - like creating a new secret 
> key, the incorrect key id shows up. [...]

I have done the same experiment, and got exactly the same results as
Alexander, except for the Key ID (2D879666 when imported with 1.4.7),
back to 17CACAE3 after creating a new keypaid using 2.0.3. But the fact
remains that modifying the key RING using 2.0.3 causes the "large key"
to resume its "phony" Key ID.

Another point to note: when trying to generate, using gpg 2.0.3, a DSA2
key (primary key 2048, E subkey 4096), I got the following error message:
- -----
gpg: WARNING: some OpenPGP programs can't handle a DSA key with this
digest size
dsa.c:187: failed assertion `nbits >= 512 && nbits <= 1024'
Abort trap
- -----

I understand the WARNING is standard, but the rest of the output clearly
shows a failure to create the requested key.

I then tried, with 2.0.3, to generate a "normal" DSA key, no problems.

To complete the test, I used 1.4.7 to generate a DSA2 key (2048 primary
key, 4096 E subkey). Keypair was created, no problem.
MacBook Intel Core 2 Duo, MacOS X 10.4.9, gpg 1.4.7, gpg2 2.0.3
Version: GnuPG v2.0.3 (Darwin)
Comment: GnuPG for Privacy
Comment: Using GnuPG with Mozilla -


More information about the Gnupg-users mailing list