I’ve been messing around with compiling GnuPG for Linux and generating big keys, and eventually I realized that GnuPG from Gpg4win can’t deal with large keys.
Running “gpg --enable-large-rsa” soon confirmed what I suspected: GnuPG is not built with large secure memory buffer support.
The point of using large keys is apparently regularly being debated (https://wiki.gnupg.org/LargeKeys), but GnuPG once used to allow the creation of keys up to 16KB and it would be nice to still be able to use (not necessarily create) such keys out of the box. As compiled now, GnuPG in Gpg4win apparently allows me to do everything with an existing 16KB key (import, sign, encrypt, decrypt), except exporting it
Is there any chance that future builds get compiled with the “–enable-large-secmem” flag? It seems to be the default notably in Ubuntu and Fedora (https://bugzilla.redhat.com/show_bug.cgi?id=1409119)
seriously I am not sure. The hard response would be:
People who chose to use a different setting as recommended by the GnuPG
core developers and many cryptographers probably have their reasons
and profound crypto knowledge, so they will be able to build their own version
of GnuPG anyway.
Someone should probably open up reports with Fedora and Ubuntu that they create usability problems if someone gets the idea to create such a large keypair. >:P
More seriously: promoting such large keys give a sense of false additional security and has other drawbacks. A good solution maybe to create new keys and use ECC or shorter RSA keys and also communicate this to your peers.
Of course there maybe a point where popular demand will make such an option
the default build for users as it is not our responsiblity to make all choices for users.
However GnuPG and Ggpg4win will also get beaten if we hint upon a direction that overall has security drawbacks (like overlong RSA keys). So it is not an easy choice.