On Thu, 2 Oct 2014 19:24, [email protected] 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. > 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. > 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. > 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. 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). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
