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

[Daniel Kahn Gillmor]

Control: tags 739424 + patch

On Wed 2014-10-01 14:01:45 -0400, Marc Lehmann wrote:
> On Wed, Oct 01, 2014 at 07:01:27PM +0200, Werner Koch <wk at gnupg.org> wrote:
>> and 3072 DSA (as per standard).  If you hack the system or use a bug to
>> create way larger keys you are on your own.
>
> Werner, please don't accuse people of "hacking systems" or exploiting bugs
> - people who used documented features in gnupg in the past, or features in
> other implementations run into this issue just as well.

Can we please dial back the vitriol on this discussion?  it's clear to
me that everyone involved wants to support people using good crypto,
let's not beat up our allies over the details, even where we disagree
with them.

> It doesn't do you well to reduce these people to those having done
> something weird. Some might have legitimate reasons, too - the most
> obvious reason is that long RSA keys are expected to last longer against
> quantum computer attacks (whether this will turn out to be true, or not,
> or unneeded is not something we can know today).
> 
> And regarding elliptic curves - you are surely aware that it is mostly
> gnupg that kept elliptic curves back in the openpgp arena.

Actually, afaict GnuPG is one of the few places where work on elliptic
curves in OpenPGP has actually happened.  It does need to be deployed
more widely, though, and getting more of the 2.1.0 betas out to a
broader audience would help (see recent discussion on gnupg-devel and
pkg-gnupg-maint about progress on that front).

>> In this case I do not want to help the race to more and more stupid key
>> properties.  If there is a problem with an 8k RSA key I am willing to
>> help, but somewhere we have to stop.

I agree with this sentiment, but we don't all agree on what the right
place to stop is.  And we've broken interoperability with old keys for
multiple users right now.

I think everyone probably agrees that trying to support > 16Kib RSA keys
is too much (16Kib RSA keys are slow to use even on modern hardware),
and there are existing interoperability concerns for people with keys
below (and close to) that cutoff, which happens to also be close to the
current best-estimate of an adversary's ~256-bit work-factor.

I don't think that anyone in the discussion actually believes they have
an adversary capable of 2^256 compute power either now or in the near
future, so presumably the disagreement is about whether the current
best-estimate might be wrong for some classes of attacker
(e.g. privately-held mathematical or hardware advances).

fwiw, recent versions of gpg also work fine with the public part of the
pre-existing larger RSA keys, although it is of course slower to do
public key operations with this sort of material.  So the concern is
just for people who hold large RSA secret keys.

If i understand it correctly, i think what changed in 1.4.16 was RSA
blinding and resistance against the acoustic attacks.  Presumably this
change ended up using more secure memory per key than had been
previously used (though i don't think i understand the exact details).
This is a critical fix, so it's clearly not something we want to revert.

I don't think i've said anything controversial so far :)

-----

GnuPG has maintained backward-compatibility (even bug-compatibility)
across much less serious concerns, so i think we should try to support
pre-existing keys as well, even if they were generated by what we see as
an earlier bug.  If GnuPG doesn't want to support this bug-compatibility
upstream, i think debian can carry a patch, though i would definitely prefer
to avoid diverging from upstream where possible.

So i'm attaching two different patches that we could use to address this
issue.  If either of them is acceptable upstream, i'll use that one.


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).


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
doubled and the max RSA size for --gen-key --batch goes from 4Kib to
8Kib.  Because the config file is parsed before secure memory is
allocated, this flag has to exist directly on the command line for
people using larger keys.


Werner, do you have a preference for which one to apply?

I think i prefer the first variant, because (a) there are already too
many command line options, and (b) a gpg option that only works on the
command line and not in the config file breaks the expected calling
conventions for gpg, and i think will be harder for most users to
deploy.  If there was a way to get the enable-large-rsa to work in
gpg.conf without parsing the configfile while under elevated privileges
(in a suid deployment -- are those still common?), i might change my
mind.

If i don't hear any objections or counterproposals, i'll probably apply
the first variant (build-time options) and set debian/rules to
./configure --enable-large-rsa-keys

Regards,

        --dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-build-time-option-for-larger-RSA-key-support.patch
Type: text/x-diff
Size: 3027 bytes
Desc: add build-time option to enable larger RSA keys
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20141002/fab2165a/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-add-runtime-support-for-larger-RSA-keys-with-enable-.patch
Type: text/x-diff
Size: 5259 bytes
Desc: add runtime option to enable larger RSA keys
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20141002/fab2165a/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20141002/fab2165a/attachment.sig>