Created attachment 400110 [details, diff] Add 'large-secmem' USE to GnuPG Two things are needed in GnuPG to use large RSA keys (>4096 bits): 1. A new local USE flag, large-secmem, to pass the --enable-large-secmem flag to GnuPG's configure. 2. A patch to raise the maximum allowed bits for RSA keys in the --gen-key interface to 8192 (if --enable-large-rsa is passed to gpg), taken from here: http://www.gossamer-threads.com/lists/gnupg/devel/70172 Also included a patch for metadata.xml. All patches are against 2.0.27, so adjust as needed for 2.0.26 or 2.1.2.
Created attachment 400112 [details, diff] Allow >4096 bits in the --gen-key interface for RSA keys
Created attachment 400114 [details, diff] metadata.xml patch for the 'large-secmem' USE flag.
why can't we wait for upstream to release a proper version?
(In reply to Alon Bar-Lev from comment #3) > why can't we wait for upstream to release a proper version? Based on upstream's reply on the referenced thread, I don't think they want the interactive interface to allow specifying keysizes >4096. --enable-large-rsa only works with --batch for generating keys by automated scripts. I don't understand their reasoning for this...perhaps it's to dissuade users from intentionally creating large keys? The explanation is not very clear, so I figured the best option was to leave the choice up to the user and remove the limitation. If anything, the 'large-secmem' USE flag should be included, since it is a configure-time switch, and --enable-large-rsa requires it even with the upstream behavior left in place.
this USE flag can be set by default. but we won't fork upstream and add features that diverse.
(In reply to Alon Bar-Lev from comment #5) > this USE flag can be set by default. > > but we won't fork upstream and add features that diverse. It's not necessarily forking upstream nor adding diverse features. The code to support the option is already present in upstream code, just not available from one particular mode of operation, interactive --gen-key. It's only available with --batch.
(In reply to Joshua Kinard from comment #6) > (In reply to Alon Bar-Lev from comment #5) > > this USE flag can be set by default. > > > > but we won't fork upstream and add features that diverse. > > It's not necessarily forking upstream nor adding diverse features. The code > to support the option is already present in upstream code, just not > available from one particular mode of operation, interactive --gen-key. > It's only available with --batch. this is forking. please convince upstream to merge this functionality. we do not touch gnupg packages.
(In reply to Alon Bar-Lev from comment #7) > (In reply to Joshua Kinard from comment #6) > > (In reply to Alon Bar-Lev from comment #5) > > > this USE flag can be set by default. > > > > > > but we won't fork upstream and add features that diverse. > > .. > > this is forking. > > please convince upstream to merge this functionality. > > we do not touch gnupg packages. Just throwing in my agreement in this. There is a marginal security gain and a high cost of RSA keys >=4096 bits. If there are needs like these, ECC should be considered (available in gnupg 2.1), but mainly focus needs to be on other aspects (operational security, side-channel attacks,platform security etc. e.g you should be more worried about libgcrypt 1.6 not being stable (bug 538488) due to this branch introducing deterministic k calculation c.f. RFC6979, versions prior to this are potentially leaking private key information for (EC)DSA operations). Upstream has made it very clear that they do not like deviation from this (as e.g. macgpg does (they also do a lot of other scary stuff, a few currently requiring gentoo devs to generate new keys due to faulty flags)). It is not the downstream's place to change any features of the application.
I'll look into badgering upstream about this then, but I still disagree that this is a fork request or an addition of new functionality. The functionality for keys larger than 4096-bits is already in the code, upstream just wants to block creation of such keys by normal key-creation methods. Maybe they'll be open to such an option if it's hidden behind --expert or such. I am finding random mailing list posts on the subject, but a lot of them are really old (i.e., during a time when 8192-bits didn't make a lot of sense).
Hi, I have an existing large RSA key, which I use as my main key. Before version 2.0.27 I used to just work but now I need the --enable-large-secmem to be able to continue using it. If I understand the discussion you don't want to patch it, which is fine; I am just asking whether you could consider adding large-secmem as a USE-Flag, please? That option is Upstream since 2.0.27.
(In reply to Sergio Perez from comment #10) > Hi, > > I have an existing large RSA key, which I use as my main key. > Before version 2.0.27 I used to just work but now I need the > --enable-large-secmem to be able to continue using it. > If I understand the discussion you don't want to patch it, which is fine; I > am just asking whether you could consider adding large-secmem as a USE-Flag, > please? > > That option is Upstream since 2.0.27. added per default in gnupg-2.0.27-r1.
