Control: reassign -1 gnupg2 Control: retitle -1 fixed length for assuan messages is too short for 4096 decryption keys
For gnupg2 maintainers: this is about an issue with gnupg2 not beeing able to decrypt stuff encrypted for 4096b keys on OpenPGP smartcards. This is caused by messages sent over assuan protocol being too large for 4096 keys. Patch attached in this bug report implements a split (think fragmentation of IP packets) in order to send the data in multiple packets. On lun., 2012-11-05 at 22:08 +0100, Heiko Schlittermann wrote: > Hi, > > thank you for responding :) > > Yves-Alexis Perez <cor...@debian.org> (Mo 05 Nov 2012 18:45:00 CET): > > On mar., 2012-10-23 at 13:12 +0200, Heiko Schlittermann wrote: > > > Package: libassuan0 > > > Version: 2.0.3-1 > > > Severity: important > > > Tags: upstream patch > > > > > > I used a 4096bit key for encryption (using the GnuPG crypto-stick). > > > Encryption worked, but decryption didn't work (gpg2 didn't find > > > the secret key.) > > > > > > gpg2 uses libassuan to talk to some daemons/agents. > > > gpg (1.x) worked, but only if there was no gnupg-agent running. > > > > > > Patch: > > > http://lists.gnupg.org/pipermail/gnupg-users/2012-June/044868.html > > > > > > I applied this patch and re-built libassuan0-* and gnupg2. This > > > seems to fix the issue. > > > > The patch is wrong, according to > > http://lists.gnupg.org/pipermail/gnupg-devel/2009-October/025412.html > > According to this above message, my crypt-stick should not expose this > bug (SN:0000113A). But it does. Well, the above message says that SN above 0x15a don't have the firmware bug but doesn't tell anything about the assuan messages size. > > > A better patch was once sent to the same mailing list the following > > month: > > http://lists.gnupg.org/pipermail/gnupg-devel/2009-November/025421.html > > by Klaus Flittner (on CC:). > > > > This was never applied because of the lack of copyright assignment. > > > > Imho this is a simple bugfix which is not even copyrightable, but IANAL. > > I've ported the patch to the current gnupg 2.0.19 in Wheezy and sid > > (it's attached). > > Ok, I'll test it here. But it will not happen sooner than thursday. And indeed, the patch is to be applied against gnupg2, not libassuan, so I'm reassigning to correct package. > > > I intend to (re)submit it to upstream but it won't work on 2.1 / git > > HEAD right now and I lack the time to properly port it right now. > > > > I think it'd still be nice to push it to gnupg in Debian so we can use > > 4096 encryption with smartcard, although it might be worth having > > upstream comment on the technical part before. > > Yep. > > I'm not able to decide, if the suggested protocol change breakes other > applications. As the line length extension broke gpa for me. I think, here > recompilation would have been sufficient, but I didn't test it. As it adds a --more argument to one command, but still support the previous usages I guess it shouldn't break other applications. And application needing to send more data than currently possible over one message can be ported to use the --more argument. So I guess it's fairly safe, but having a comment from upstream would be nice indeed. Regards, -- Yves-Alexis
signature.asc
Description: This is a digitally signed message part
