Ohhhh jeeee: can't encode a 512 bit MD into a 608 bits frame

[NIIBE Yutaka]

Hello,

Thank you for more information.

On 05/27/2015 08:53 PM, Philip Jackson wrote:
> I tried to re-import it into the original desktop system to see if the problem
> recurred.  (I should have done that before writing the last mail, to confirm
> fault). With the original desktop : gpg 1.4.16 and gpg2 2.0.22, Thunderbird with
> enigmail 1.8.2 :
[...]
> gpg: Ohhhh jeeee: can't encode a 512 bit MD into a 608 bits frame
> Aborted (core dumped)

I think that 2.0.22 has this problem.  I checked 2.0 series commit logs.

I think that It was handled by the commit:

    http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=6286d01ba33b963be30fbb4fba6f35f1b05acd17

commit 1f842011f611625c8a5fd852d5a2b4bd13e4b563
Author: Werner Koch <wk at gnupg.org>
Date:   Fri Oct 4 18:01:40 2013 +0200

    gpg: Kludge not to bail out on ECC if build with Libgcrypt 1.6.

    * g10/misc.c (print_pubkey_algo_note): Map the algo.
    (openpgp_pk_test_algo, openpgp_pk_test_algo2): Ditto.
    (pubkey_get_npkey, pubkey_get_nskey, pubkey_get_nsig)
    (pubkey_get_nenc): Return 0 for ECC algorithms.
    --

    Libgcrypt 1.6 features algorithm 18 (generic ECC).  Because of the
    missing mapping and no real support for the OpenPGP ECC format, this
    led to parsing errors of ECC packets.  We better better explicitly
    tell gpg that we ECC is not supported.

    Signed-off-by: Werner Koch <wk at gnupg.org>

It was done soon after 2.0.22.  I think that 2.0.23 or later doesn't
have this issue.  The signature check is just skipped as unknown algo.

> I have other keys in my public keyring which also have ECC subkeys
> and these do not cause any difficulty either with enigmail or
> gpg2.0.22

I think that it occurs because it has SHA512 signature.  I guess that
other keys with ECC subkeys in your keyring has SHA256 signature.
--