Gnupg cannot handle extremely large keys on 32 bit Linux

Charly Avital shavital at
Sat Apr 14 20:34:51 CEST 2007

Ludwig Hügelschäfer wrote the following on 4/14/07 8:57 PM:
> Hi,
> Charly Avital wrote on 14.04.2007 18:17 Uhr:
>> *Therefore, there is a difference in results (Key ID and fpr) when the
>> keyblock is imported from Thunderbird+Enigmail (inside option), and when
>> the same keyblock is saved in a stand-along file that is imported via CLI*.
> I just deleted the mentioned key from my keyring and reimported it using
> enigmails import function by clicking on "decrypt".
> The key still identifies in the same way (0x2D879666, fingerprint
> BCA2 2448 8F7C 5646 A94A CE16 35BE A302 2D87 9666) afterwards.
> Running TB (20070414) + Enigmail nightly 0.95b (20070409)
> Which combination do you run?
> Ludwig, cc'ing to the enigmail list.


The most recent comments by Alexander Feigl point at the possibility
that gpg 2.0.3 is writing out the key incorrectly, in such a way that
gpg 1.4.7 does not recognize it.

Following that comment, I have already posted to the list that I am
running TB+Enigmail using gpg 2.0.3, and not gpg 1.4.7.

When I imported Alexander Feigl's large key, using the 'Decrypt' icon
(in TB + Enigmail 0.95.0) or the OpenPGP option 'Sender's
key>Import Public Key (in TB + Enigmail 0.94.3), I was using
gpg 2.0.3.

If indeed gpg 2.0.3 is writing out the key incorrectly, why it is doing so?

Just to remind what was happening:
- although TB+Enigmail/gpg 2.0.3 indicated that it was going to import a
key whose key ID was 2D879666, the key that was imported had the key ID
- gpg --edit-key 2D879666 did not find such a key.
- gpg --edit-key 17CACAE3 found a key that showed a self signature made
  with 2D879666
- but when the key block was imported through CLI as a copy/paste/saved
  file (i.e. *not* via TB+Enigmail/gpg 2.0.3), the imported key was
  2D879666, without any mention of 17CACAE3.



More information about the Gnupg-users mailing list