Bug#749335: Oldstable GnuPG no longer capable of using large keys

2014-06-24 Thread Lance Hathaway
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

2014-05-26 Thread Lance Hathaway
-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