On 10/02/2014 02:42 PM, Werner Koch wrote: > On Thu, 2 Oct 2014 19:24, d...@fifthhorseman.net said: > >> public key operations with this sort of material. So the concern is >> just for people who hold large RSA secret keys. > > That would be easy because those can easily use a configure option etc > to adjust things for them.
Most users don't think that rebuilding a package, even with just changing a config option, falls under the heading of "easily", unfortunately. >> If i understand it correctly, i think what changed in 1.4.16 was RSA >> blinding and resistance against the acoustic attacks. Presumably this > > Right, that is probably the reason. We should have the same problem > with 2.x depending on the Libgcrypt versions. gpg 2.x also reserves 32k > memory (gpgsm even only 16k). However some details are different. I can verify that we do have the same problem with 2.x, i just haven't looked into how to fix it yet. >> The first variant adds a compile-time flag: ./configure >> --enable-large-rsa-keys, which defaults to off. If it is present, then >> we allocate double the secmem (64KiB instead of 32KiB) and permit up to >> 8Kib RSA keys when doing --gen-key --batch (the upper limit on >> interactive key generation remains at 4Kib). > > I am 100% fine with the first part of it. The second part puts new > firewood up to the we-need-larger-keys campfire, thus I like to ask not > to do that. Marc et al may still create larger keys if they really want > that. I am pretty sure they know how to change it. I considered having the configure option boost the max --gen-key --batch size to 16Kib -- aren't you glad i only pushed it to 8Kib? :) >> The second variant adds a runtime flag: gpg --enable-large-rsa , which >> defaults to off. If the flag is present at runtime, then the secmem is > > I considered such an option several times in the past but it is tricky > as you noted: We can't allow to put it into the conf file because that > would but too much code at the risk of being run under elevated > privileges (for those systems which still require that for mlock). > Although I won't like it, setting a flag to allow large key generation > would be okay here. it sounds like you might be willing to consider a combination of the two patches. What would you think about the following proposal? * ./configure --enable-large-rsa-keys doubles the secmem size * gpg --enable-large-rsa option (acceptable either on the command line or in the config file) (a) produces a warning when built without the ./configure option, or (b) bumps the upper limit to 8192 bits during --batch --key-gen > We need this for gpg 2 as well. However, it might be a better idea to > implement that via a global Libgcrypt configuration file. gpg could > then take that secure memory value from that file (Libgcrypt 1.7). If you're OK with this proposal for gpg1, i'll make a patch for it and then look into what needs to be done for 2.x. Thanks for considering this, --dkg
signature.asc
Description: OpenPGP digital signature