Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Key size
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Key size and encryption system== 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}}</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>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)