Bug#749335: Oldstable GnuPG no longer capable of using large keys
On Sun, 1 Jun 2014 12:51, intrig...@debian.org said: oldstable than in testing/sid: it's one thing to accept upstream's newly set limits in testing/sid; it's an entirely different thing to For the records, GnuPG never supported keys larger than keys you can create with GnuPG, which is for RSA 4096 bit. Largers keys may or may not work. Salam-Shalom, Werner p.s. A 16k key is actually the worst thing one can do and actually decreases overall security. -- 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#749335: Oldstable GnuPG no longer capable of using large keys
On Tuesday, June 24, 2014 11:26:07 AM, Werner Koch w...@gnupg.org wrote: For the records, GnuPG never supported keys larger than keys you can create with GnuPG, which is for RSA 4096 bit. Largers keys may or may not work. I would like to state, for the record, that I -did- use GnuPG to create these keys. More to the point, I used -stock- GnuPG (unmodified) to create my 16k key. Specifically, I used batch mode to do so, as the menu-driven system had a hard upper limit on key size. GnuPG -can- (or could, since I haven't tested it recently) create RSA keys larger than 4096 bits in length, without any modification. I knew from the start that GnuPG does not countenance the use of key sizes larger than 4k, and it is not my intention to re-open that debate. However, the software worked. It worked to create the keys, and it worked to utilize the keys. I didn't have to change anything in the code or re-compile anything with new options. It just worked. Also for the record, I mostly agree with GnuPG's decision re: the 4k limit on creating new keys through the menu interface. It wasn't easy to figure out how to create a large keypair with stock GnuPG, and that information is probably best left obscure. But it could be done--and GnuPG worked with the resulting keys normally. Now, GnuPG simply doesn't allow me to make signatures with the large key any more. Perhaps a large part of my frustration / confusion stems from a lack of understanding. Obviously something changed between the version that worked and the version that does not. I don't know enough to figure out what code changed to impact this functionality, and I certainly don't understand why. From what I've been able to tell, this is purely a matter of allocating more secure memory, as if the allocation was reduced at some point. I don't know whether this was part of the fix for CVE-2013-4576 (if so, why was this impacted?), or if it was another code change rolled into the same update (if so, why the reduction [if it was a reduction]?). Could you possibly shed some light on this? p.s. A 16k key is actually the worst thing one can do and actually decreases overall security. I'm afraid I don't understand this at all. I do understand the arguments about creating a false sense of security, the need to preserve compatibility with low-power devices and older software, and etc., but I haven't heard anything about why a 16k key is the worst thing one can do, such that it actually decreases overall security. Could you please elaborate further? -Lance -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749335: Oldstable GnuPG no longer capable of using large keys
Hi, Lance Hathaway wrote (26 May 2014 14:00:10 GMT) : Attempting to sign other keys with the larger key causes GnuPG to immediately die with an out of secure memory message, as also reported in bug #739424. (Though that bug is filed against a different version.) Indeed, that's a duplicate of #739424. I'm not merging these two bugs, though, as the maintainers may want to handle it differently on oldstable than in testing/sid: it's one thing to accept upstream's newly set limits in testing/sid; it's an entirely different thing to introduce functionality regressions in oldstable (and I guess stable) security updates. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749335: Oldstable GnuPG no longer capable of using large keys
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: gnupg Version: 1.4.10-4+squeeze4 X-Debbugs-CC: intrig...@debian.org First-time bug reporter here, so my apologies in advance if I've left something out or committed any faux pas. I use TAILS to help safeguard my master GPG keypairs, of which I have two. The first (for general use) is a 4096-bit key. The second (for long-term identity) is a 16384-bit key. Up to and including TAILS 0.22, I was able to use both keys with stock GnuPG. From TAILS 0.22.1 onwards, I can only use the smaller key. Attempting to sign other keys with the larger key causes GnuPG to immediately die with an out of secure memory message, as also reported in bug #739424. (Though that bug is filed against a different version.) I have verified that the old versions of GnuPG in TAILS 0.22 continue to work correctly. I copied the GnuPG executable out of TAILS 0.22 and into TAILS 1.0, and ran both executables against the larger key. The version shipped with 1.0 dies as described, but the imported version from 0.22 works correctly. The changelog from TAILS 0.22 to 0.22.1 includes the update to GnuPG described in DSA-2821-1, but nothing more. Since both versions of GnuPG report themselves as 1.4.10, I am assuming that TAILS is tracking Debian oldstable, and I have therefore filed this bug against that version. -Lance -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBCgAGBQJTg0jnAAoJEECmBqfoBgXnxlAP/2GvKizXzG/kTZGmg68YUsxL 0/eZGbSK5nQ/EP+ez8qc9hiUPceJ+PBBXErSoEm2EXSUaPPCauIr9Xuh5upEVBI2 rTw0kt3LzKpxdQqbxUJ/m0Zr+hyd+QCdRA7AejNLbp1q7jrjmYdGRKFJqSWP5e7Y CKS7QwMt0ctI0fHfB7s4lO8wZ2l1g2XhmSV318jukSyGFJpJKyIzRqPdx6NQ9Mx6 C99LHhWjBdneJP24d/w/KTwK2Ct2CNc4iY8Oln0gVsh4IAktDrtW4h3wz04pXp8Y cUyqVuYE9eExVBD/Im9GCeXWLPZ02UaQFRQFt2Y60vqYLPhDGqPCVUz00ztecdPi ptL0fyDKd/F6nuAwBqlMHqcCqqTo7sv218K8lmfoR0rZ6FhblQONffNwiWa1MNCE 0/+Sw7f84SRNjJUsz4I+Q54e03lMusmdXX3oNKIYhwVZlYns/fDq0Eg1hWWx3DMF 8vi8UT9stTt7ncnDymENiDONKtW+cVLNO8TjybDT6VTpMDYWkJIh/R9lWadXbpB4 h43D/9/otgVzPflASw7wI/888URi4WscmLeNB2hEjxw5wYhjKcWbRpFVPHE+Kwde tXVlZO1hMMAtS/5oG/A3EW3WFErWO/d6NZSvgalJ0qkNj90Nqu5FTXSXZyW7PjfA NOyW8JUJQeYfT3uWpDqU =Ognd -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