[Pkg-gnupg-maint] Bug#739424: Bug#739424: gnupg dies with "gpg: out of secure memory [...]" since 1.4.16-1

[Daniel Kahn Gillmor]

On 10/02/2014 02:42 PM, Werner Koch wrote:
> On Thu,  2 Oct 2014 19:24, dkg at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20141002/cc5956de/attachment.sig>