|
Size: 2360
Comment: link to the FAQ default seciton discussion added
|
← Revision 17 as of 2024-10-07 08:13:25 ⇥
Size: 4084
Comment: - typo
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| When creating a new certificate, there is a choice of how long to select the size of the private key. | = Large keys |
| Line 3: | Line 3: |
| As of October 2014 the **default of ~GnuPG** is to use RSA with a length 2048bit. This is the recommendation because the ~GnuPG Initiative believe this serves most users best. Please check out the [[https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048|FAQs on keysize]]. |
When generating a new key pair, advanced users can choose the bitlength for the RSA algorithm. |
| Line 7: | Line 5: |
| There is an ongoing debate about what the future default length should be and what sizes should be supported. You will find it on gnupg-users. |
From GnuPG version 2.2.22 (August 2020) the default is an 3072 RSA keypair. (Before, **~GnuPG's default** was an 2048 bit RSA keypair and the [[https://www.gnupg.org/faq/gnupg-faq.html#default_rsa2048|FAQs on keysize]] (accessed 2020-08-28) still has the old reasoning.) |
| Line 10: | Line 8: |
| Note that Werner Koch, the principle author of ~GnuPG recommends to not use private keysizes larger than 4 Kibibyte, he believes 8 KiB to be a practical upper limit that ~GnuPG should technically support. E.g. see his statement in [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739424#30|Debian Issue739424 ]] |
The recommendation is made to serve most users best. |
| Line 13: | Line 10: |
| The main arguments (~TODO) are: * ~GnuPG needs to ensure (somewhat) secure memory, because of ~DDOS attacks there must be a limit on supported keysizes. * With larger private keysizes there are drawbacks in performance, especially on small systems (think drained battery). This lead to a less usable and thus |
On the gnupg-users mailing list it is discussed sometimes what the future default length should be and what sizes should be supported. Note that the principle author of ~GnuPG, **Werner Koch recommends to not use private keys larger than 4 KiB when using RSA**. He believes 8 KiB to be a practical upper limit that ~GnuPG should technically support. See, for instance, his statement in [[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739424#30|Debian Issue739424]]. Since version 2.0.27 and 1.4.19 GnuPG can be compiled with {{{--enable-large-secmem}}} to offer an {{{--enable-large-rsa}}} option that can create keys up to 8 KiB. Some elder versions supported creating of keys up to 16 KiB. The main arguments (~TODO needs more checking of completeness) are: * ~GnuPG needs to ensure (somewhat) secure memory, and because of ~DDoS attacks there must be a limit on supported keysizes. * With larger private keysizes there are drawbacks in performance, especially on small systems (may causing a drained battery). This leads to a less usable and thus |
| Line 17: | Line 22: |
| * While larger keys may provide some more security against breaking the RSA encryption math, it can only be estimated how much extra security more bits provide. As most mathemathical threats do not come by brute force, it is unclear how much more protection very large keys can provide. * There are sending implementations of ~OpenPGP that only support a certain upper limit (e.g. OpenPGP cards are known to go to 3 KiB or 4 KiB in some versions. ~GnuPG 1.4.18 cannot use ~>= 5KiB keys anymore). * There may be receiving implementation of ~OpenPGP that only support a certain upper limit of key size. * With keysizes larger as 2 KiB today (October 2014), it is extremely likely that there are many other weaker spots in your security. If you care about security, it is rational to deal with these weaknesses first before you consider raising the key sizes. The weaker spots are likely to be vulnerabilities in your computing environment, in the implementation of ~OpenPGP you are using and in your procedures to verify certificates. |
* While larger keys may provide some more security against breaking the RSA encryption math, it can only be estimated how much extra security more bits provide, it is not a linear increase. As most mathematical threats do not come by brute force, it is unclear how much more protection very large keys can provide. * Sending side of communication: There are ~OpenPGP implementations that only encrypt or sign up to a certain upper limit (e.g. OpenPGP cards are known to go to 3 KiB or 4 KiB in some versions. ~GnuPG 1.4.18 cannot use ~>= 5KiB keys anymore). * Receiving side of communication: There may be ~OpenPGP implementations that only decrypt or verify up to a certain upper limit of key size. * With keysizes larger than 2 KiB today (October 2014), it is extremely likely that there are many other weaker spots in your security. If you care about security, it is rational to deal with these weaknesses first before you consider raising the key sizes. The weaker spots are likely to be vulnerabilities in your computing environment, in the implementation of ~OpenPGP you are using or in your procedures to verify certificates. [[https://lwn.net/Articles/735840/|LWN on Werner Koch's talk at Kernel Recipies 2017]] has: //RSA, he said, is not likely to stay secure for much longer without really large keys. Support for 4096-bit RSA keys has been in GnuPG for some time, but Koch contends// [Note by editor: [[https://en.wiktionary.org/wiki/contend|disputes]]] //that real security will require 16Kb keys; that makes keys, fingerprints, and signatures all unusably long, particularly for embedded devices and hardware security modules (~HSMs).// //Koch showed examples of digital signatures of comparable security, one made with RSA-4096 and one with Ed25519// [..] //HSM timing data showed that RSA is about 60 times slower than Ed25519 for signing.// == Other rationales * https://www.keylength.com/ provides an interactive overview and links to a number of recommendations. * https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.1.pdf * https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf#page=66 == History * In 2009 GnuPG switched the default for Open~PGP key creation from {{{dsa1024/elg2048}}} to RSA/RSA 2048. The discussion is archived around https://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025079.html |
Large keys
When generating a new key pair, advanced users can choose the bitlength for the RSA algorithm.
From GnuPG version 2.2.22 (August 2020) the default is an 3072 RSA keypair. (Before, GnuPG's default was an 2048 bit RSA keypair and the FAQs on keysize (accessed 2020-08-28) still has the old reasoning.)
The recommendation is made to serve most users best.
On the gnupg-users mailing list it is discussed sometimes what the future default length should be and what sizes should be supported.
Note that the principle author of GnuPG, Werner Koch recommends to not use private keys larger than 4 KiB when using RSA. He believes 8 KiB to be a practical upper limit that GnuPG should technically support. See, for instance, his statement in Debian Issue739424. Since version 2.0.27 and 1.4.19 GnuPG can be compiled with --enable-large-secmem to offer an --enable-large-rsa option that can create keys up to 8 KiB. Some elder versions supported creating of keys up to 16 KiB.
The main arguments (TODO needs more checking of completeness) are:
- GnuPG needs to ensure (somewhat) secure memory, and because of DDoS attacks there must be a limit on supported keysizes.
- With larger private keysizes there are drawbacks in performance, especially on small systems (may causing a drained battery). This leads to a less usable and thus also slightly less secure system (through the "threat" that crypto is less often used because of the inconvenience of time and battery it takes to use it).
- While larger keys may provide some more security against breaking the RSA encryption math, it can only be estimated how much extra security more bits provide, it is not a linear increase. As most mathematical threats do not come by brute force, it is unclear how much more protection very large keys can provide.
- Sending side of communication: There are OpenPGP implementations that only encrypt or sign up to a certain upper limit (e.g. OpenPGP cards are known to go to 3 KiB or 4 KiB in some versions. GnuPG 1.4.18 cannot use >= 5KiB keys anymore).
- Receiving side of communication: There may be OpenPGP implementations that only decrypt or verify up to a certain upper limit of key size.
- With keysizes larger than 2 KiB today (October 2014), it is extremely likely that there are many other weaker spots in your security. If you care about security, it is rational to deal with these weaknesses first before you consider raising the key sizes. The weaker spots are likely to be vulnerabilities in your computing environment, in the implementation of OpenPGP you are using or in your procedures to verify certificates.
LWN on Werner Koch's talk at Kernel Recipies 2017 has:
RSA, he said, is not likely to stay secure for much longer without really large keys. Support for 4096-bit RSA keys has been in GnuPG for some time, but Koch contends [Note by editor: disputes] that real security will require 16Kb keys; that makes keys, fingerprints, and signatures all unusably long, particularly for embedded devices and hardware security modules (HSMs).
Koch showed examples of digital signatures of comparable security, one made with RSA-4096 and one with Ed25519 [..] HSM timing data showed that RSA is about 60 times slower than Ed25519 for signing.
Other rationales
- https://www.keylength.com/ provides an interactive overview and links to a number of recommendations.
- https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.1.pdf
- https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf#page=66
History
- In 2009 GnuPG switched the default for OpenPGP key creation from dsa1024/elg2048 to RSA/RSA 2048. The discussion is archived around https://lists.gnupg.org/pipermail/gnupg-devel/2009-May/025079.html