Cryptographic Key Length Recommendation

In most cryptographic functions, the key length is an important security parameter. Both academic and private organizations provide recommendations and mathematical formulas to approximate the minimum key size requirement for security. Despite the availability of these publications, choosing an appropriate key size to protect your system from attacks remains a headache as you need to read and understand all these papers.

This web site implements mathematical formulas and summarizes reports from well-known organizations allowing you to quickly evaluate the minimum security requirements for your system. You can also easily compare all these techniques and find the appropriate key length for your desired level of protection. The lengths provided here are designed to resist mathematic attacks; they do not take algorithmic attacks, hardware flaws, etc. into account.

Choose a Method
ECRYPT is a network of excellence in cryptology. This report [3] is driven by the "Security Level" you want to reach. To each of these levels corresponds a symmetric key size from which equivalent asymmetric key sizes are built in a similar way as the one used in NESSIE.
Level Protection Symmetric Asymmetric
Discrete Logarithm
Key Group
Elliptic Curve Hash
1 Attacks in "real-time" by individuals
Only acceptable for authentication tag size
32 -
- -
- -
2 Very short-term protection against small organizations
Should not be used for confidentiality in new systems
64 816
128 816
128 128
3 Short-term protection against medium organizations,
medium-term protection against small organizations
72 1008
144 1008
144 144
4 Very short-term protection against agencies,
long-term protection against small organizations
Smallest general-purpose level,
2-key 3DES restricted to 240 plaintext/ciphertexts,
protection from 2014 to 2015
80 1248
160 1248
160 160
5 Legacy standard level
2-key 3DES restricted to 106 plaintext/ciphertexts,
protection from 2014 to 2020
96 1776
192 1776
192 192
6 Medium-term protection
3-key 3DES, protection from 2014 to 2030
112 2432
224 2432
224 224
7 Long-term protection
Generic application-independent recommendation,
protection from 2014 to 2040
128 3248
256 3248
256 256
8 "Foreseeable future"
Good protection against quantum computers,
unless Shor’s algorithm applies
256 15424
512 15424
512 512
All key sizes are provided in bits. These are the minimal sizes for security.
Click on a value to compare it with other methods.
The 32 and 64-bit levels should not be used for confidentiality protection; 32-bit keys offer no confidentiality at all relative to any attacker, and 64-bit offers only very poor protection. Nevertheless, there are applications where these levels may be necessary if security is to be provided at all, e.g. for integrity tags.

While both 80 and 128-bit keys provide sufficient security against brute force key-search attacks (on symmetric primitives) by the most reasonable adversaries, it should be noted that 80 bits would be practically breakable and 128 bits might correspond to an effective 80-bit level, if one considers attack models based on pre-computation and large amounts of available storage. As a simple rule of thumb, one may choose to double the key size to mitigate threats from such attacks.

The main consideration for a secure hash function is the size of the outputs. If the application requires collisions to be difficult to find, the output must be twice the desired security level. This is the case e.g. when used with digital signatures. When used as a keyed hash for message authentication, however, the outputs may often be truncated. MD5 has to be considered completely broken from collision resistance point of view (explicit collisions can be demonstrated), and SHA-1 provides only a very marginal security.

Note that the discrete logarithm and elliptic curve recommendations applies for prime order fields. For finite field discrete logarithm schemes, the table may need to be revised taking into account more efficient attacks that are known to exist for discrete logarithm over binary fields. However, ECRYPT members are not aware of any practical deployment of systems based on discrete logarithms in binary fields.
For elliptic curve, recommendations for binary fields need to take into account that the field size should be 2p, where p is a prime number of bit-size slightly larger than the group/key bit-size (unless p is a prime, more efficient attacks are known). If in addition, the special purpose hardware of [11] is considered a threat, roughly an additional 10 bits should be added to the elliptic curve key size in this case.
© 2014 BlueKrypt - v 27.8 - October 21, 2013
Author: Damien Giry
Approved by Prof. Jean-Jacques Quisquater
Contact:
Surveys of laws and regulations on cryptology: Crypto Law Survey / Digital Signature Law Survey.
Bibliography[1] Selecting Cryptographic Key Sizes, Arjen K. Lenstra and Eric R. Verheul, PKC2000: p. 446-465, 01/2000.
[2] Handbook of Information Security, Arjen K. Lenstra, 06/2004.
[3] Yearly Report on Algorithms and Keysizes (2012), D.SPA.20 Rev. 1.0, ICT-2007-216676 ECRYPT II, 09/2012.
[4] Recommendation for Key Management, Special Publication 800-57 Part 1 Rev. 3, NIST, 07/2012.
[5] Mécanismes cryptographiques - Règles et recommandations, Rev. 1.20, ANSSI , 01/2010.
[6] Fact Sheet Suite B Cryptography, NSA, 05/2013.
[7] Determining Strengths for Public Keys Used for Exchanging Symmetric Keys, RFC 3766, H. Orman and P. Hoffman, 04/2004.
[8] Algorithms for Qualified Electronic Signatures, BNetzA, BSI, 02/2013 updated with BSI Draft, 10/2013.
[11] Parallel Collision Search with Cryptanalytic Applications, P. C. van Oorschot and M. J. Wiener, Journal of Cryptology 12:1, 1999.
Privacy Policy (P3P)  |  Disclaimer / Copyright  |  Release Notes