Key size: Difference between revisions

Jump to navigation Jump to search
imported>Chris the speller
m Significance: replaced: commonly-used → commonly used
 
imported>Mesocyclonic93
m Reverted 1 edit by ~2026-13089-04 (talk) to last revision by Adakiko
 
Line 14: Line 14:
Encryption systems are often grouped into families. Common families include symmetric systems (e.g. [[Advanced Encryption Standard|AES]]) and asymmetric systems (e.g. [[RSA (algorithm)|RSA]] and [[Elliptic-curve cryptography]] [ECC]). They may be grouped according to the central [[algorithm]] used (e.g. [[Elliptic-curve cryptography|ECC]] and [[Feistel cipher]]s). Because each of these has a different level of cryptographic complexity, it is usual to have different key sizes for the same [[level of security]], depending upon the algorithm used. For example, the security available with a 1024-bit key using asymmetric [[RSA (cryptosystem)|RSA]] is considered approximately equal in security to an 80-bit key in a symmetric algorithm.<ref name=NISTSP800-131Ar2/>
Encryption systems are often grouped into families. Common families include symmetric systems (e.g. [[Advanced Encryption Standard|AES]]) and asymmetric systems (e.g. [[RSA (algorithm)|RSA]] and [[Elliptic-curve cryptography]] [ECC]). They may be grouped according to the central [[algorithm]] used (e.g. [[Elliptic-curve cryptography|ECC]] and [[Feistel cipher]]s). Because each of these has a different level of cryptographic complexity, it is usual to have different key sizes for the same [[level of security]], depending upon the algorithm used. For example, the security available with a 1024-bit key using asymmetric [[RSA (cryptosystem)|RSA]] is considered approximately equal in security to an 80-bit key in a symmetric algorithm.<ref name=NISTSP800-131Ar2/>


The actual degree of security achieved over time varies, as more computational power and more powerful mathematical analytic methods become available. For this reason, cryptologists tend to look at indicators that an algorithm or key length shows signs of potential vulnerability, to move to longer key sizes or more difficult algorithms. For example, {{As of|2007|05|lc=on}}, a 1039-bit integer was factored with the [[special number field sieve]] using 400 computers over 11 months.<ref>{{cite magazine |url=http://www.pcworld.com/article/132184/article.html |title=Researcher: RSA 1024-bit Encryption not Enough |magazine=PC World |date=2007-05-23 |access-date=2016-09-24 }}{{Dead link|date=June 2025 |bot=InternetArchiveBot |fix-attempted=yes }}</ref> The factored number was of a special form; the special number field sieve cannot be used on RSA keys. The computation is roughly equivalent to breaking a 700 bit RSA key. However, this might be an advance warning that 1024 bit RSA keys used in secure online commerce should be [[deprecation|deprecated]], since they may become breakable in the foreseeable future. Cryptography professor [[Arjen Lenstra]] observed that "Last time, it took nine years for us to generalize from a special to a nonspecial, hard-to-factor number" and when asked whether 1024-bit RSA keys are dead, said: "The answer to that question is an unqualified yes."<ref>{{cite web |first=Jacqui |last=Cheng |url=https://arstechnica.com/news.ars/post/20070523-researchers-307-digit-key-crack-endangers-1024-bit-rsa.html |title=Researchers: 307-digit key crack endangers 1024-bit RSA |work=Ars Technica |date=2007-05-23 |access-date=2016-09-24}}</ref>
The actual degree of security achieved over time varies, as more computational power and more powerful mathematical analytic methods become available. For this reason, cryptologists tend to look at indicators that an algorithm or key length shows signs of potential vulnerability, to move to longer key sizes or more difficult algorithms. For example, {{As of|2007|05|lc=on}}, a 1039-bit integer was factored with the [[special number field sieve]] using 400 computers over 11 months.<ref>{{cite magazine |url=http://www.pcworld.com/article/132184/article.html |title=Researcher: RSA 1024-bit Encryption not Enough |magazine=PC World |date=2007-05-23 |access-date=2016-09-24 |archive-date=2016-06-24 |archive-url=https://web.archive.org/web/20160624173438/http://www.pcworld.com/article/132184/article.html |url-status=dead }}</ref> The factored number was of a special form; the special number field sieve cannot be used on RSA keys. The computation is roughly equivalent to breaking a 700 bit RSA key. However, this might be an advance warning that 1024 bit RSA keys used in secure online commerce should be [[deprecation|deprecated]], since they may become breakable in the foreseeable future. Cryptography professor [[Arjen Lenstra]] observed that "Last time, it took nine years for us to generalize from a special to a nonspecial, hard-to-factor number" and when asked whether 1024-bit RSA keys are dead, said: "The answer to that question is an unqualified yes."<ref>{{cite web |first=Jacqui |last=Cheng |url=https://arstechnica.com/news.ars/post/20070523-researchers-307-digit-key-crack-endangers-1024-bit-rsa.html |title=Researchers: 307-digit key crack endangers 1024-bit RSA |work=Ars Technica |date=2007-05-23 |access-date=2016-09-24}}</ref>


The 2015 [[Logjam (computer security)|Logjam attack]] revealed additional dangers in using Diffie-Hellman key exchange when only one or a few common 1024-bit or smaller prime moduli are in use. This practice, somewhat common at the time, allows large amounts of communications to be compromised at the expense of attacking a small number of primes.<ref name="logjam">{{cite web |url=https://weakdh.org |title=Weak Diffie-Hellman and the Logjam Attack |website=weakdh.org |date=2015-05-20}}</ref><ref>{{cite conference |url=https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf |archive-url=https://ghostarchive.org/archive/20221010/https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf |archive-date=2022-10-10 |url-status=live |first1=David |last1=Adrian |first2=Karthikeyan |last2=Bhargavan |first3=Zakir |last3=Durumeric |first4=Pierrick |last4=Gaudry |first5=Matthew |last5=Green |first6=J. Alex |last6=Halderman |first7=Nadia |last7=Heninger |first8=Drew |last8=Springall |first9=Emmanuel |last9=Thomé |first10=Luke |last10=Valenta |first11=Benjamin |last11=VanderSloot |first12=Eric |last12=Wustrow |first13=Santiago |last13=Zanella-Béguelin |first14=Paul |last14=Zimmermann |conference=22nd ACM Conference on Computer and Communications Security (CCS '15) |location=Denver, CO |date=October 2015 |title=Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice}}</ref>
The 2015 [[Logjam (computer security)|Logjam attack]] revealed additional dangers in using Diffie-Hellman key exchange when only one or a few common 1024-bit or smaller prime moduli are in use. This practice, somewhat common at the time, allows large amounts of communications to be compromised at the expense of attacking a small number of primes.<ref name="logjam">{{cite web |url=https://weakdh.org |title=Weak Diffie-Hellman and the Logjam Attack |website=weakdh.org |date=2015-05-20}}</ref><ref>{{cite conference |url=https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf |archive-url=https://ghostarchive.org/archive/20221010/https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf |archive-date=2022-10-10 |url-status=live |first1=David |last1=Adrian |first2=Karthikeyan |last2=Bhargavan |first3=Zakir |last3=Durumeric |first4=Pierrick |last4=Gaudry |first5=Matthew |last5=Green |first6=J. Alex |last6=Halderman |first7=Nadia |last7=Heninger |first8=Drew |last8=Springall |first9=Emmanuel |last9=Thomé |first10=Luke |last10=Valenta |first11=Benjamin |last11=VanderSloot |first12=Eric |last12=Wustrow |first13=Santiago |last13=Zanella-Béguelin |first14=Paul |last14=Zimmermann |conference=22nd ACM Conference on Computer and Communications Security (CCS '15) |location=Denver, CO |date=October 2015 |title=Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice}}</ref>
Line 64: Line 64:
{{blockquote|"A cryptanalytically-relevant quantum computer (CRQC) would have the potential to break public-key systems (sometimes referred to as asymmetric cryptography) that are used today. Given foreign pursuits in quantum computing, now is the time to plan, prepare and budget for a transition to [quantum-resistant] QR algorithms to assure sustained protection of [National Security Systems] NSS and related assets in the event a CRQC becomes an achievable reality."<ref name=cnsasuite>{{cite web|url=https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/ |title=NSA Releases Future Quantum-Resistant (QR) Algorithm Requirements for National Security Systems |date=2022-09-07 |publisher=[[National Security Agency]] |access-date=2024-04-14}}</ref>}}
{{blockquote|"A cryptanalytically-relevant quantum computer (CRQC) would have the potential to break public-key systems (sometimes referred to as asymmetric cryptography) that are used today. Given foreign pursuits in quantum computing, now is the time to plan, prepare and budget for a transition to [quantum-resistant] QR algorithms to assure sustained protection of [National Security Systems] NSS and related assets in the event a CRQC becomes an achievable reality."<ref name=cnsasuite>{{cite web|url=https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3148990/nsa-releases-future-quantum-resistant-qr-algorithm-requirements-for-national-se/ |title=NSA Releases Future Quantum-Resistant (QR) Algorithm Requirements for National Security Systems |date=2022-09-07 |publisher=[[National Security Agency]] |access-date=2024-04-14}}</ref>}}


Since September 2022, the NSA has been transitioning from the [[Commercial National Security Algorithm Suite]] (now referred to as CNSA 1.0), originally launched in January 2016, to the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), both summarized below:<ref name=nsaCNSA>{{cite web|url=https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF |archive-url=https://archive.today/20221121213740/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF |url-status=dead |archive-date=November 21, 2022 |title=Announcing the Commercial National Security Algorithm Suite 2.0, U/OO/194427-22, PP-22-1338, Ver. 1.0 |date=September 2022 |publisher=[[National Security Agency]]|website=media.defense.gov|access-date=2024-04-14|at=Table IV: CNSA 2.0 algorithms, p. 9.; Table V: CNSA 1.0 algorithms, p. 10.}}</ref>{{efn|See the complete tables and the transition timeline at [[Commercial National Security Algorithm Suite]] article.}}
Since September 2022, the NSA has been transitioning from the [[Commercial National Security Algorithm Suite]] (now referred to as CNSA 1.0), originally launched in January 2016, to the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), both summarized below:<ref name=nsaCNSA>{{cite web|url=https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF |archive-url=https://archive.today/20221121213740/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF |url-status=dead |archive-date=November 21, 2022 |title=Announcing the Commercial National Security Algorithm Suite 2.0, U/OO/194427-22, PP-22-1338, Ver. 1.0 |date=September 2022 |publisher=[[National Security Agency]]|website=United States Department of Defense|access-date=2024-04-14|at=Table IV: CNSA 2.0 algorithms, p. 9.; Table V: CNSA 1.0 algorithms, p. 10.}}</ref>{{efn|See the complete tables and the transition timeline at [[Commercial National Security Algorithm Suite]] article.}}


'''CNSA 2.0'''
'''CNSA 2.0'''
Line 144: Line 144:


==Further reading==
==Further reading==
* [http://csrc.nist.gov/publications/PubsSPs.html ''Recommendation for Key Management &mdash; Part 1: general,''] NIST Special Publication 800-57. March, 2007
* [http://csrc.nist.gov/publications/PubsSPs.html ''Recommendation for Key Management &mdash; Part 1: general,''] {{Webarchive|url=https://web.archive.org/web/20170912090949/http://csrc.nist.gov/publications/PubsSPs.html |date=2017-09-12 }} NIST Special Publication 800-57. March, 2007
* Blaze, Matt; Diffie, Whitfield; Rivest, Ronald L.; et al. "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security". January, 1996
* Blaze, Matt; Diffie, Whitfield; Rivest, Ronald L.; et al. "Minimal Key Lengths for Symmetric Ciphers to Provide Adequate Commercial Security". January, 1996
* Arjen K. Lenstra, Eric R. Verheul: Selecting Cryptographic Key Sizes. J. Cryptology 14(4): 255-293 (2001) &mdash; [http://citeseer.ist.psu.edu/lenstra99selecting.html Citeseer link]
* Arjen K. Lenstra, Eric R. Verheul: Selecting Cryptographic Key Sizes. J. Cryptology 14(4): 255-293 (2001) &mdash; [http://citeseer.ist.psu.edu/lenstra99selecting.html Citeseer link]
Line 151: Line 151:
* [https://www.keylength.com/ www.keylength.com: An online keylength calculator]
* [https://www.keylength.com/ www.keylength.com: An online keylength calculator]
* [https://web.archive.org/web/20140101053420/http://www.synaptic-labs.com/resources/expert-opinions/94-quantum-computing.html Articles discussing the implications of quantum computing]
* [https://web.archive.org/web/20140101053420/http://www.synaptic-labs.com/resources/expert-opinions/94-quantum-computing.html Articles discussing the implications of quantum computing]
* NIST [http://csrc.nist.gov/groups/ST/toolkit cryptographic toolkit]
* NIST [http://csrc.nist.gov/groups/ST/toolkit cryptographic toolkit] {{Webarchive|url=https://web.archive.org/web/20150820045057/http://csrc.nist.gov/groups/ST/toolkit/ |date=2015-08-20 }}
* [[Burt Kaliski]]: [https://apj.emc.com/emc-plus/rsa-labs/historical/twirl-and-rsa-key-size.htm TWIRL and RSA key sizes] (May 2003)
* [[Burt Kaliski]]: [https://apj.emc.com/emc-plus/rsa-labs/historical/twirl-and-rsa-key-size.htm TWIRL and RSA key sizes] (May 2003)