As i mentioned in T4591, modern gpg normally doesn't want to load a super-large certificate (the only cases i've seen certificates that large is when they are the victim of a certificate flooding attack).
But they can still import a large certificate if they use the old-style keyring format (instead of keybox), and they might have just inherited them from a previous installation.
When such a certificate is present, it causes a massive slowdown. 33 seconds on a fast, modern machine just to list the certificate itself! I recompiled the head of STABLE-BRANCH-2-2 of GnuPG with -pg and profiled with gprof:
0 dkg@alice:/tmp/cdtemp.7QJ3xD$ time ~/src/gnupg/gnupg2/g10/gpg --list-keys gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! /tmp/cdtemp.7QJ3xD/pubring.gpg ------------------------------ pub ed25519 2019-01-19 [C] [expires: 2021-01-18] C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 uid [ unknown] Daniel Kahn Gillmor <email@example.com> uid [ unknown] Daniel Kahn Gillmor <firstname.lastname@example.org> sub ed25519 2019-01-19 [S] [expires: 2020-01-19] sub ed25519 2019-01-19 [A] [expires: 2020-01-19] sub cv25519 2019-01-19 [E] [expires: 2020-01-19] real 0m33.610s user 0m33.529s sys 0m0.081s 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ gprof ~/src/gnupg/gnupg2/g10/gpg > list-keys.gprof.txt
Attached are the statistics of that run:
even deleting the key is computationally expensive, taking more than 1 minute to delete the only certificate in the keyring, yielding this profiling data:
I don't know how to read gprof output particularly well, but both of these files point toward add_kb_node as the biggest culprit.
One thing that i observe is that just parsing the 17MiB of packets is *not* expensive with gpg generally:
0 dkg@alice:/tmp/cdtemp.7QJ3xD$ time gpg --list-packets < example.key > /dev/null real 0m0.513s user 0m0.500s sys 0m0.013s 0 dkg@alice:/tmp/cdtemp.7QJ3xD$