Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
* Marc Lehmann: NIST 2012 also recommends similar key sizes (15360 bits). NIST is being abit disingenuous there. There is no published material which shows that such long keys actually add any security. For all we know, they may well offer only reduced security because the large modulus reduces mixing or something like that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Tue, Oct 21, 2014 at 06:29:33PM +0200, Florian Weimer f...@deneb.enyo.de wrote: NIST 2012 also recommends similar key sizes (15360 bits). NIST is being abit disingenuous there. There is no published material which shows that such long keys actually add any security. For all we know, they may well offer only reduced security because the large modulus reduces mixing or something like that. Um, where to begin... this is not even wrong. It's established fact that longer rsa keys do add security (and there is a large pool of publications showing so), which is why a 1024 bit rsa key (very long by standards 20 years ago) is not considered generally safe anymore. The only open question is how much security longer keys add, and if it helps against (fictituous) quantum computers, but at the very least, you still need a bigger quantum computer to crack longer key lengths, if it is even possible. By contrast, you are arguing for known worse security because of unknown reasons of why longer keys *might* be less safe. While this is true, any key length could be unsafe against future algorithms - for all we know, future algorithms will influence secure key lenghts in unknown ways. Or in other words, we just don't know. So you argue that, because we don't know future attacks, we must go for less security now by not even allowing people to use longer keys (or their existing keys at all!). This is illogical, and again I question the motives behind this social downgrade attack: arguing for known worse security because of handwave, but the future might - we can only act by what we know *now*. Calling NIST disingenous because they don't throw their hands up and say oooh, the unknown future, why don't we give up now is weird. What NIST does is called best practise - no cryptography is safe against unknown future attacks. With your argument anything is unsafe, because the future might bring efficient attacks against smaller rsa keys, against elliptic curves, against very long rsa keys and so on just as well. We just don't know. What we do know is that forcing people to downgrade key lengths and change their keys to be interoperable with the only openpgp implementation that can't cope with longer keys does reduce security - everything else is just made up. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Wed, Oct 01, 2014 at 10:48:44PM +0200, Werner Koch w...@gnupg.org wrote: Werner, please don't accuse people of hacking systems or exploiting bugs If you think of the term hacking in any negative way, I conclude that Werner, can you just stop twisting words? The term you used is hack the system - hacking systems doesn't have the positive connotations as hacking software for example, especially not when you use bugs to achieve that, sorry, but real hackers don't use bugs to hack systems. If anybody used the word hacking with negative conotations, it's you. that we don't use the same code for communication. No, Werner, you are simply dishonest in your communication, so much is clear now. In this whole thread you were misrepresenting facts, quoting out of context, and making false statements. The big problem is that apart from that, you didn't do anything else - there was no attempt to answer questions, explain your sometimes insulting claims, or reconcile your position with the documented and published position of crypto experts. I seriously question your motives now. I also agree to end this exchange here, it doesn't lead anywhere when one party is obviously not interested in a technical discussion, but only in ridiculing the problem and twisting words. My hope at this point is simply that debian works around this. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: [Pkg-gnupg-maint] Bug#739424: Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Thu, 2 Oct 2014 22:06, d...@fifthhorseman.net said: Attached is a patch (a third variant) for gpg's 1.4 stable branch that does what i've outlined above. let me know what you think. Okay, okay, I give up ;-) Please do not i18n the warning string. We already have too many rarley used strings translated. Note: with this patch, for aesthetic reasons, i've also changed the configure option to --enable-large-rsa, so that the build-time and run-time options are symmetric. Another idea: What about using --enable-secmem=65536 and change the warning to check that the supplied size is sufficient? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: [Pkg-gnupg-maint] Bug#739424: Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On 10/03/2014 02:47 AM, Werner Koch wrote: On Thu, 2 Oct 2014 22:06, d...@fifthhorseman.net said: Attached is a patch (a third variant) for gpg's 1.4 stable branch that does what i've outlined above. let me know what you think. Okay, okay, I give up ;-) ;) Please do not i18n the warning string. We already have too many rarley used strings translated. OK, will do. Note: with this patch, for aesthetic reasons, i've also changed the configure option to --enable-large-rsa, so that the build-time and run-time options are symmetric. Another idea: What about using --enable-secmem=65536 and change the warning to check that the supplied size is sufficient? I like that, since it makes the ./configure option clearer about what it's doing. Alternately, we could just call it --enable-large-secmem (--enable-larger-secmem?), so that people can't do silly things like --enable-secmem=17 or --enable-secmem=bananas Assuming we go with the variable size configure option, i don't know how to test that the supplied size is sufficient for generating 8192-bit keys -- i suppose i can just use: #if SECMEM_SIZE = 65536 // accept --enable-large-rsa #else // warn that enable-large-rsa won't work #endif which is no worse than the current proposal. Going down this route suggests that maybe the actual upper-limit to gpg --gen-key --batch --enable-large-rsa should scale with the declared SECMEM_SIZE, instead of being either 4096 or 8192, but i don't know how to compute such a scale aside from experimentation on any given platform. Let me know how you prefer it, and i'll roll up one final patch. Thanks for persisting on this, Werner. Regards, --dkg signature.asc Description: OpenPGP digital signature
Bug#739424: [Pkg-gnupg-maint] Bug#739424: Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Fri, 3 Oct 2014 17:00, d...@fifthhorseman.net said: I like that, since it makes the ./configure option clearer about what it's doing. Alternately, we could just call it --enable-large-secmem Okay. #if SECMEM_SIZE = 65536 // accept --enable-large-rsa #else // warn that enable-large-rsa won't work #endif which is no worse than the current proposal. Right. Going down this route suggests that maybe the actual upper-limit to gpg --gen-key --batch --enable-large-rsa should scale with the declared SECMEM_SIZE, instead of being either 4096 or 8192, but i don't know how to compute such a scale aside from experimentation on any given platform. Too complicated. Better use what you suggested above. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: [Pkg-gnupg-maint] Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
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 w...@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
Bug#739424: [Pkg-gnupg-maint] Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
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. 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 debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: [Pkg-gnupg-maint] Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
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
Bug#739424: [Pkg-gnupg-maint] Bug#739424: Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Thu 2014-10-02 15:23:10 -0400, Daniel Kahn Gillmor wrote:
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 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
Attached is a patch (a third variant) for gpg's 1.4 stable branch that
does what i've outlined above. let me know what you think.
Note: with this patch, for aesthetic reasons, i've also changed the
configure option to --enable-large-rsa, so that the build-time and
run-time options are symmetric.
--dkg
From c09b57360a57e47d6fac120b7bec88e8eb27a34e Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor d...@fifthhorseman.net
Date: Thu, 2 Oct 2014 10:58:54 -0400
Subject: [PATCH] add build and runtime support for larger RSA keys
* configure.ac: added --enable-large-rsa option
* g10/options.h: add opt.flags.large_rsa
* g10/gpg.c: contingent on configure option: adjust secmem size,
add gpg --enable-large-rsa, bound to opt.flags.large_rsa
* g10/keygen.c: adjust max RSA size based on opt.flags.large_rsa
* doc/gpg.texi: document --enable-large-rsa
--
Some older implementations built and used RSA keys up to 16Kib, but
the larger secret keys now fail when used by more recent GnuPG, due to
secure memory limitations.
Building with ./configure --enable-large-rsa-keys will make gpg
capable of working with those secret keys, as well as permitting the
use of a new gpg option --enable-large-rsa, which let gpg generate RSA
keys up to 8Kib when used with --batch --gen-key.
Debian-bug-id: 739424
---
configure.ac | 16
doc/gpg.texi | 9 +
g10/gpg.c | 26 +-
g10/keygen.c | 5 +++--
g10/options.h | 1 +
5 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac
index ae63a4a..0648679 100644
--- a/configure.ac
+++ b/configure.ac
@@ -158,6 +158,7 @@ use_exec=yes
card_support=yes
agent_support=yes
disable_keyserver_path=no
+large_rsa_support=no
AC_ARG_ENABLE(minimal,
AC_HELP_STRING([--enable-minimal],[build the smallest gpg binary possible]),
@@ -177,6 +178,21 @@ AC_ARG_ENABLE(minimal,
agent_support=no)
+AC_MSG_CHECKING([whether larger RSA keys should be supported])
+AC_ARG_ENABLE(large-rsa,
+ AC_HELP_STRING([--enable-large-rsa],
+ [enable large RSA keys]),
+ large_rsa_support=$enableval, large_rsa_support=no)
+AC_MSG_RESULT($large_rsa_support)
+
+if test $large_rsa_support = yes ; then
+ AC_DEFINE(SECMEM_BUFFER_SIZE,65536,[Size of secure memory buffer])
+ AC_DEFINE(LARGE_RSA_KEYS,1,[Define to support large RSA keys])
+else
+ AC_DEFINE(SECMEM_BUFFER_SIZE,32768,[Size of secure memory buffer])
+fi
+
+
AC_MSG_CHECKING([whether OpenPGP card support is requested])
AC_ARG_ENABLE(card-support,
AC_HELP_STRING([--disable-card-support],
diff --git a/doc/gpg.texi b/doc/gpg.texi
index ded69ce..ae86809 100644
--- a/doc/gpg.texi
+++ b/doc/gpg.texi
@@ -1104,6 +1104,15 @@ the opposite meaning. The options are:
validation. This option is only meaningful if pka-lookups is set.
@end table
+@item --enable-large-rsa
+@itemx --disable-large-rsa
+@opindex enable-large-rsa
+@opindex disable-large-rsa
+With --gen-key and --batch, enable the creation of larger RSA secret
+keys than is generally recommended (up to 8192 bits). These large
+keys are more expensive to use, and their signatures and
+certifications are also larger.
+
@item --enable-dsa2
@itemx --disable-dsa2
@opindex enable-dsa2
diff --git a/g10/gpg.c b/g10/gpg.c
index 1b0a364..1fe6caf 100644
--- a/g10/gpg.c
+++ b/g10/gpg.c
@@ -372,6 +372,8 @@ enum cmd_and_opt_values
oAutoKeyLocate,
oNoAutoKeyLocate,
oAllowMultisigVerification,
+oEnableLargeRSA,
+oDisableLargeRSA,
oEnableDSA2,
oDisableDSA2,
oAllowMultipleMessages,
@@ -719,6 +721,8 @@ static ARGPARSE_OPTS opts[] = {
{ oDebugCCIDDriver, debug-ccid-driver, 0, @},
#endif
{ oAllowMultisigVerification, allow-multisig-verification, 0, @},
+{ oEnableLargeRSA, enable-large-rsa, 0, @},
+{ oDisableLargeRSA, disable-large-rsa, 0, @},
{ oEnableDSA2, enable-dsa2, 0, @},
{ oDisableDSA2, disable-dsa2, 0, @},
{ oAllowMultipleMessages, allow-multiple-messages, 0, @},
@@ -1948,6 +1952,10 @@ main (int argc, char **argv )
set_homedir ( pargs.r.ret_str );
else if( pargs.r_opt == oNoPermissionWarn )
opt.no_perm_warn=1;
+ else if( pargs.r_opt == oEnableLargeRSA )
+ opt.flags.large_rsa=1;
+ else if( pargs.r_opt == oDisableLargeRSA )
+ opt.flags.large_rsa=0;
else if (pargs.r_opt == oStrict )
{
opt.strict=1;
@@ -1995,7 +2003,7 @@ main (int argc, char **argv )
}
#endif
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Tue, Sep 30, 2014 at 09:17:02AM +0200, Werner Koch w...@gnupg.org wrote: Please read the FAQ and if you disagree, feel free to re-open the discussion for yet another round on gnupg-users. Werner, again - nothing in the FAQ can change the fact that you are wrong in claiming that these key sizes are stupid, when _actual_ crypto experts disagree. I am more than tired of the those key size matters discussions. Key size clearly matters, which is why people no longer use rsa-512 or DES, and which is why people movew away from (standard 1024 bit) dsa. Furthermore, characterising this bug as key size matters is again disingenous, as _you_ are the one claiming this: This ticket is simply about an arbitrary limit which hampers interoperation - nobody tries to convince you to go for longer keys by default, recomemnd them, or anything like that. The fix would be trivial without sacrificing any security. I can understand if you misread/misunderstood this ticket - we are all very busy. If that is the case, maybe you could go back and actually take care of the issue reported, instead of hammering on a topic that is irrelevant here? have to take the whole system in account and not just one aspect. 16k keys are ridiculous and dangerous for the hole crypto environment. Calling things ridiculous doesn't make them so: when actual crypto experts disagree with you, you need to bring a bit more to the table than simply calling things ridiculous. How are they dangerous? At the moment, the only danger is in gpg, as other implementations do not have this arbitrary limit, which creates a very real danger of forcing people to not encrypt to solve interoperability issues with gnupg. You only look at technical arguments and not on arguments regarding usability. Actually, it is you who ignores usability - you are proposing to kepe the status quo, which means existing keys are unusable until somebody patches gnupg. Only a few 16k signature on a lot of keys makes the WoT re-checking slow. Only if you enable it, that's what people are asking for here. Gnupg already dynamically allocates the memory. Having an option would be trivial. It is you who ignores usability here. multi-recipient messages stops the workflow and makes people consider to switch off encryption. I think the issue here was keysigning, not signing you e-mail. Different keys, diuferent use cases, so your argument doesn't apply. smaller machines. Thus it harms the overall usability of the system just for a few strawmen's misdirected huge key size is better opinion. Again, you are the one who makes this huge key size is better claim - I don't think anybody else did this in this ticket. You have provided zero evidence in favour of not fixing this bug, but Marc, pretty please read the FAQ. Again, nothing in the FAQ can magically make your previous statements right. In any case, it seems you are arguing against a completely different issue here - you really should go back and read this ticket. I won't continue to discuss this here anymore. How well you maintain gnupg is your choice. precious for repeating the same arguments over and over again. Since you didn't repeat any argument so far, there is no danger of you repeatign yourself. Claiming this is ridiculous is not an argument. gnupg-users and you will find a lot of people who have enough time to discuss this with you. Again, no amount of discussion can change facts. you do not want fix this bug, keeping keysizes in gnupg arbitrarily low for your own private reasons. I do not know whether or what you want to imply withn that claim. It sounds quite insulting, though. I want to imply exactly what I wrote - the limit is currently arbitrary and low compared to othe rimplementations, and stating this is ridiculous is not a valid reason, so the actual reasons why you refuse to fix this are, indeed, your own private ones. If you don't like the facts, don't feel insulted. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Wed, 1 Oct 2014 17:05, schm...@schmorp.de said: Key size clearly matters, which is why people no longer use rsa-512 or DES, and which is why people movew away from (standard 1024 bit) dsa. I am talking about ridiculous large key sizes for the given systems (Debian on standard CPUs). We use defaults, which are generally considered good (2048 bit RSA), and allow the use of up to 4096 bit RSA 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. The fix would be trivial without sacrificing any security. It is sometimes better not to fix things. 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 won't continue to discuss this here anymore. How well you maintain gnupg is your choice. You noticed the here? Again: Please continue this discussion on a suitable mailing list - I suggest gnupg-users. Feel free to forward all these mails to gnupg-users. Drop me a note if this needs moderation. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Wed, Oct 01, 2014 at 07:01:27PM +0200, Werner Koch w...@gnupg.org wrote: How well you maintain gnupg is your choice. You noticed the here? Again: Please continue this discussion on a suitable mailing list - I suggest gnupg-users. Here is a perfectly fine place to discuss bugs in debian packages, which this ticket is all about. Moving to a mailinglist would be wrong. If you don't want to discuss it here, that's fine of course. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Wed, Oct 01, 2014 at 07:01:27PM +0200, Werner Koch w...@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. 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. The fix would be trivial without sacrificing any security. It is sometimes better not to fix things. Well, obviously not in this case. 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. Werner, you repeatedly call these key sizes stupid, even though I have shown that professional crypto experts disagree with that (do any agree with you?). What's the point? Just because you (a non-cryptographer¹) thinks these are stupid doesn't make them so. You are _of course_ entitled to your opinion, but it's really just an opinion that is in disagreement with the experts in the field. That's not a basis for good crypto, and certainly not a good reason not to fix this in Debian GNU/Linux. (1) I certainly respect you for your cryptographic knowledge, as a coder, and certainly as a human being with interesting input, but we both maintain GNU crypto software, and we are both just coders, not cryptography professionals. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Wed, 1 Oct 2014 20:01, schm...@schmorp.de said: Werner, please don't accuse people of hacking systems or exploiting bugs If you think of the term hacking in any negative way, I conclude that that we don't use the same code for communication. Let's both stop this fruitless debate. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Tue, 30 Sep 2014 06:56, schm...@schmorp.de said: Werner, I find your reply disingenious - I cannot believe that you are not aware that what you are writing is misleading and/or outright wrong. Please read the FAQ and if you disagree, feel free to re-open the discussion for yet another round on gnupg-users. I am more than tired of the those key size matters discussions. It is plainly wrong. You have to take the whole system in account and not just one aspect. 16k keys are ridiculous and dangerous for the hole crypto environment. This is a strawman argument - which attacks would gnupg open itself up if it increased the limit to be sufficient for longer keysizes recommended You only look at technical arguments and not on arguments regarding usability. Only a few 16k signature on a lot of keys makes the WoT re-checking slow. Having to encrypt to just one of those keys in a multi-recipient messages stops the workflow and makes people consider to switch off encryption. Maybe not on your machine but definitely on all smaller machines. Thus it harms the overall usability of the system just for a few strawmen's misdirected huge key size is better opinion. You have provided zero evidence in favour of not fixing this bug, but Marc, pretty please read the FAQ. I won't continue to discuss this here anymore. Sorry. My time is too precious for repeating the same arguments over and over again. Go to gnupg-users and you will find a lot of people who have enough time to discuss this with you. I am sorry, that some keys broke due to the recent security update. The reason why it was possible to create such keys in the first place was actually a bug in GnuPG which didn't limit the keysize when generating it from a parameters file. These are all expert options and if you are an expert it is plausible to assume that an expert knows how to evaluate security. Shalom-Salam, Werner ps. you do not want fix this bug, keeping keysizes in gnupg arbitrarily low for your own private reasons. I do not know whether or what you want to imply withn that claim. It sounds quite insulting, though. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
NIST 2012 also recommends similar key sizes (15360 bits). These are only projections to show that there is a need to switch to EC keys. Regarding the key size I can only point to the FAQ and the endless discussions on gnupg-users. It is also against the GNU coding standards to have arbitrary limits such as these. (Avoid arbitrary limits on the length or number of any data The GNU standards partly recommend ideas dating back to a time the Internet was young and innocent. Nowadays connecting a box to the Internet means to vulnerable to a wide range of of attacks. Having no limits on input data and allocating buffer dynamically is a an easy way to DoS a service. If you look at GnuPG code you will notice that there is no silent truncation of lines. If there is one, please report it as a bug. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
Werner, I find your reply disingenious - I cannot believe that you are not aware that what you are writing is misleading and/or outright wrong. On Mon, Sep 29, 2014 at 08:58:26AM +0200, Werner Koch w...@gnupg.org wrote: NIST 2012 also recommends similar key sizes (15360 bits). These are only projections to show that there is a need to switch to EC keys. That might be your interpretation of the intent of their recommendations (specifically, SP 800/57), but the facts still remain that experts do not agree with you (disagreeing with your own claims). It also doesn't invalidate the opinion of the other expert opinions provided (which you have conveniently left out of your reply). It is also against the GNU coding standards to have arbitrary limits such as these. (Avoid arbitrary limits on the length or number of any data The GNU standards partly recommend ideas dating back to a time the Internet was young and innocent. Nowadays connecting a box to the Internet means to vulnerable to a wide range of of attacks. This is a strawman argument - which attacks would gnupg open itself up if it increased the limit to be sufficient for longer keysizes recommended by many crpytographic researchers, as requested in this ticket? Having no limits on input data and allocating buffer dynamically is a an easy way to DoS a service. Again a strawman - firstly, gnupg can support the recommended keysizes without dynamically allocating a buffer, and secondly, gnupg already allocates the buffer in question dynamically. It simply places an arbitrary (and very low) limit on the buffer. If you look at GnuPG code you will notice that there is no silent truncation of lines. Werner, go and read the it: It says any data structure, not just line lengths. I am sure you already know that, but why this disingenuous comment about line lengths? This bug report is not about line lengths, but about arbitrary limits. You have provided zero evidence in favour of not fixing this bug, but instead only strawmen and misleading arguments. I can only conclude that you do not want fix this bug, keeping keysizes in gnupg arbitrarily low for your own private reasons. -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi! I'm running into the same issue after the latest update on Ubuntu. This is the bug I opened: https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1371766 Is there really a reason to break compatibility with currently used keys? Cheers Ciaby -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iF4EAREKAAYFAlQcjmoACgkQC30ZhxNccpH1mAD+LWh/vb5YzKCwZACRVLA5bQ7I D3F6OixCaRD+g1K7OEIA/RxMHzHW/QLtBDIeb/JzLJHOLTQRwniB2v167hUwhb/2 =yRPW -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
Package: gnupg Version: 1.4.16-1.1 Followup-For: Bug #739424 Dear Maintainer, I suffer from the same problem with a 15424 bit rsa key, which makes gnupg essentially unusable as well. As for Werner Koch calling these key sizes stupid, the recommended RSA key size for the forseeable future, good protection against quantum computers using Shor's algorithm according to ECRYPT II 2012 is indeed 15424 bits (http://www.keylength.com/en/3/), so it seems quite a few crypto exyperts disagree with him here. NIST 2012 also recommends similar key sizes (15360 bits). It is also against the GNU coding standards to have arbitrary limits such as these. (Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility). In think debian should fix this bug, even if the upstream author is stubborn about it. Especially if there are no known arguments speaking against it. -- System Information: Debian Release: 7.5 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.1-031601-generic (SMP w/12 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg depends on: ii gpgv 1.4.12-7+deb7u4 ii libbz2-1.01.0.6-5 ii libc6 2.19-1 ii libreadline6 6.2+dfsg-0.1 ii libusb-0.1-4 2:0.1.12-23.3 ii zlib1g1:1.2.7.dfsg-13 Versions of packages gnupg recommends: pn gnupg-curl none ii libldap-2.4-2 2.4.31-1+nmu2 Versions of packages gnupg suggests: pn gnupg-doc none ii imagemagick 8:6.7.7.10-5+deb7u3 ii libpcsclite1 1.8.11-3 -- no debconf information -- debsums errors found: prelink: /opt/bin/leaplogin: Could not find one of the dependencies prelink: /opt/bin/dasdcat: Could not find one of the dependencies prelink: /opt/bin/gvpectrl.n900: Using /lib/ld-linux.so.3, not /lib/ld-linux.so.2 as dynamic linker prelink: /opt/bin/dasdls: Could not find one of the dependencies prelink: /opt/bin/hercifc: Could not find one of the dependencies prelink: /opt/bin/hetget: Could not find one of the dependencies prelink: /opt/bin/cckddiag: Could not find one of the dependencies prelink: /opt/bin/netscape: Could not find one of the dependencies prelink: /opt/bin/cem: Could not find one of the dependencies prelink: /opt/bin/shgenSBRDF: Could not find one of the dependencies prelink: /opt/bin/Grimrock: Could not find one of the dependencies prelink: /opt/bin/cckdswap: Could not find one of the dependencies prelink: /opt/bin/cadaverserver: Could not find one of the dependencies prelink: /opt/bin/catrats: Could not find one of the dependencies prelink: /opt/bin/ckd2cckd: Could not find one of the dependencies prelink: /opt/bin/cckdcomp: Could not find one of the dependencies prelink: /opt/bin/tapecopy: Could not find one of the dependencies prelink: /opt/bin/dasdseq: Could not find one of the dependencies prelink: /opt/bin/pakx: Could not find one of the dependencies prelink: /opt/bin/dasdisup: Could not find one of the dependencies prelink: /opt/bin/tapesplt: Could not find one of the dependencies prelink: /opt/bin/dasdinit: Could not find one of the dependencies prelink: /opt/bin/cadaverspyboss: Could not find one of the dependencies prelink: /opt/bin/hercules: Could not find one of the dependencies prelink: /opt/bin/shrike: Could not find one of the dependencies prelink: /opt/bin/hetmap: Could not find one of the dependencies prelink: /opt/bin/dmap2hrc: Could not find one of the dependencies prelink: /opt/bin/shgenmap: Could not find one of the dependencies prelink: /opt/bin/ckd2cckd: Could not find one of the dependencies prelink: /opt/bin/cckdcdsk: Could not find one of the dependencies prelink: /opt/bin/dasdload: Could not find one of the dependencies prelink: /opt/bin/ccgo: Could not find one of the dependencies prelink: /opt/bin/ckd2cckd: Could not find one of the dependencies prelink: /opt/bin/shgencubemap: Could not find one of the dependencies prelink: /opt/bin/hetinit: Could not find one of the dependencies prelink: /opt/bin/ndump: Could not find one of the dependencies prelink: /opt/bin/dasdpdsu: Could not find one of the dependencies prelink: /opt/bin/tapemap: Could not find one of the dependencies prelink: /opt/bin/pakc: Could not find one of the dependencies prelink: /opt/bin/ckd2cckd: Could not find one of the dependencies prelink: /opt/bin/ckd2cckd: Could not find one of the dependencies prelink: /opt/bin/nstats: Could not find one of the dependencies prelink: /opt/bin/v4l2info: Could not find one of the dependencies prelink: /opt/bin/shsparse: Could not find one of the dependencies prelink: /opt/bin/hetupd: Could not find one of the dependencies prelink:
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
Werner Koch, w...@gnupg.org, wrote: On Tue, 18 Feb 2014 18:26, r...@debian.org said: 10240-bit RSA key, ID 4A11C97A, created 2009-09-23 ^^ !!! gpg: (this may be caused by too many secret keys used simultaneously or due to excessive large key sizes) There are reasons why upstream gpg does not allow the creation of such stupidly long keys. The fix for being able to deal with such key-sizes seems rather trivial, though. gnupg-1.4.16/g10/gpg.c:1998 got_secmem=secmem_init( 32768 ); Changing that to, say, 262144 (*8) lets GnuPG deal with keys ~5kBit. A quick test shows that it can deal with 16kBit keys with that value, but 32kBit are still too much. I do think that in Good Old Internet Tradition (be liberal in what you accept) it'd be fine to change that value. It still won't let you *create* keys 4kBit anyway, just deal with situations where the user (or a correspondent, in case of the user wanting to sign such a thing) has created such large keys with something else. Kind regards, -robert -- -- A militant agnostic is someone who's credo is -- No, I don't know, and NEITHER DO YOU, DAMMIT! -- (partly) Kevin Martin, asr signature.asc Description: Digital Signature
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
On Tue, 18 Feb 2014 18:26, r...@debian.org said: 10240-bit RSA key, ID 4A11C97A, created 2009-09-23 ^^ !!! gpg: (this may be caused by too many secret keys used simultaneously or due to excessive large key sizes) There are reasons why upstream gpg does not allow the creation of such stupidly long keys. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739424: gnupg dies with gpg: out of secure memory [...] since 1.4.16-1
Package: gnupg Version: 1.4.15-3 Severity: important Hi, Since gnupg was updated to 1.4.16-1, it fails to sign or decrypt with the error gpg: out of secure memory while allocating 640 bytes. I've using the same key on the same system without issue since 2009, but since the upgrade to 1.4.16-1, gnupg has become essentially unusable. See below for an example of the problem; please let me know if I can provide you with any additional information. Best wishes, Ryan ryan@nu:/tmp$ dpkg --list gnupg | grep ii | gpg --clearsign You need a passphrase to unlock the secret key for user: Ryan Kavanagh r...@debian.org 10240-bit RSA key, ID 4A11C97A, created 2009-09-23 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 ii gnupg 1.4.16-1 amd64GNU privacy guard - a free PGP replacement gpg: out of secure memory while allocating 640 bytes gpg: (this may be caused by too many secret keys used simultaneously or due to excessive large key sizes) ryan@nu:/tmp$ wget -q http://snapshot.debian.org/archive/debian/20131220T215322Z/pool/main/g/gnupg/gnupg_1.4.15-3_amd64.deb ryan@nu:/tmp$ sudo dpkg -i gnupg_1.4.15-3_amd64.deb [sudo] password for ryan: dpkg: warning: downgrading gnupg from 1.4.16-1 to 1.4.15-3 (Reading database ... 453599 files and directories currently installed.) Preparing to unpack gnupg_1.4.15-3_amd64.deb ... Unpacking gnupg (1.4.15-3) over (1.4.16-1) ... Setting up gnupg (1.4.15-3) ... Processing triggers for man-db (2.6.6-1) ... Processing triggers for install-info (5.2.0.dfsg.1-2) ... ryan@nu:/tmp$ dpkg --list gnupg | grep ii | gpg --clearsign You need a passphrase to unlock the secret key for user: Ryan Kavanagh r...@debian.org 10240-bit RSA key, ID 4A11C97A, created 2009-09-23 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 ii gnupg 1.4.15-3 amd64GNU privacy guard - a free PGP replacement -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQUcBAEBCgAGBQJTA5PEAAoJEI97+PxKEcl6E5AoAKa0kKQ4IDrekP0ucJc7UBUo [SNIP] =BtXh -END PGP SIGNATURE- ryan@nu:/tmp$ gpg --list-key 4A11C97A | grep -v uid gpg: DBG: locking for `/home/ryan/.gnupg/trustdb.gpg.lock' done via O_EXCL pub 10240R/4A11C97A 2009-09-23 [expires: 2016-01-25] sub 10240R/0F5E9C64 2009-09-24 [expires: 2019-09-22] ryan@nu:/tmp$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63062 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 95 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 63062 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnupg depends on: ii gpgv 1.4.16-1 ii libbz2-1.01.0.6-5 ii libc6 2.17-97 ii libreadline6 6.2+dfsg-0.1 ii libusb-0.1-4 2:0.1.12-23.3 ii zlib1g1:1.2.8.dfsg-1 Versions of packages gnupg recommends: pn gnupg-curl none ii libldap-2.4-2 2.4.31-1+nmu2+b1 Versions of packages gnupg suggests: pn gnupg-doc none ii imagemagick 8:6.7.7.10-7 ii libpcsclite1 1.8.11-1 -- no debconf information -- |_)|_/ Ryan Kavanagh | Debian Developer | \| \ http://ryanak.ca/ | GPG Key 4A11C97A signature.asc Description: Digital signature
