Description of problem: gpg has a hard coded crypto throttle in place, restricting asymmetric keys to 4096 bits. In contrast, the NIST standard "Recommendation for Key Management, Special Publication 800-57 Part 1 Rev. 3, NIST, 07/2012" is recommending key sizes of 15360 bits to be used with 256 bit symmetric ciphers. 65535 has been reported to work and to be a reasonable limit, above which key generation takes too long to make sense. (Trivial) patch is at https://deekayen.net/large-gpg-keys Version-Release number of selected component (if applicable): gnupg2-2.0.22-1.fc19.i686 How reproducible: always Steps to Reproduce: 1. gpg2 --gen-key Actual results: gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) Expected results: gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 1 RSA keys may be between 1024 and 65535 bits long. What keysize do you want? (2048)
While the change is trivial, it is an enhancement that should best be done upstream, wouldn't it? Also: With the new ECC initiative in Fedora, won't we be able to use ECC keys? Or are they still banned by RH legal?
(In reply to Michael J Gruber from comment #1) > While the change is trivial, it is an enhancement that should best be done > upstream, wouldn't it? Yes, I agree. > Also: With the new ECC initiative in Fedora, won't we be able to use ECC > keys? Or are they still banned by RH legal? The support for ECDSA/ECDH is only in the development branch of gnupg upstream.
(In reply to Michael J Gruber from comment #1) > While the change is trivial, it is an enhancement that should best be done > upstream, wouldn't it? According to http://gagravarr.livejournal.com/137173.html upstream is refusing to make that change, with strange justifications: "they think that for most people going to 8192 bits will just make things slower, without delivering much more security, so they feel that anyone who wants a longer key should have to think about it, and explicitly enable it themselves."
I can confirm that upstream is refusing to make this change because of performance issues. I think when it comes to security performance must not matter.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Bug still present. Please reopen and change version to F24.
Depends if fedora's maintainer(s) agree with upstream (close->wontfix) or not (patch around it).
I do not agree fully with the upstream reasoning as there might be valid reasons to use large keys, on the other hand I am not so sure it is worth the effort to patch it downstream. If someone provided such patch (including documentation changes) I would apply it though.
People have done this before: https://deekayen.net/large-gpg-keys https://lists.gnupg.org/pipermail/gnupg-devel/2014-October/028930.html
gnupg2-2.2.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-22bee61e57
gnupg2-2.2.0-1.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2017-a43ed4a971
This bug report is marked as modified, but I don't see any indication that this bug is really fixed. Neither the upstream release announcement nor its NEWS or README file indicate any change related to this bug report, as does the Fedora spec file on https://src.fedoraproject.org/rpms/gnupg2/commits/master. I think there has been a mistake here.
The Fedora spec contains the change and it enables the upstream large RSA key support = 8192 bit keys. We will not deviate from upstream in enabling even larger keys.
(In reply to Tomas Mraz from comment #14) > The Fedora spec contains the change and it enables the upstream large RSA > key support = 8192 bit keys. We will not deviate from upstream in enabling > even larger keys. Ok, thanks for the hint and sorry for the noise.
gnupg2-2.2.0-1.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-22bee61e57
gnupg2-2.2.0-1.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-a43ed4a971
gnupg2-2.2.0-1.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
gnupg2-2.2.0-1.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.